Bug 618798

Filesystem is just package with basic directory layout. It has nothing to do with ext3/4 - reassigning to kernel.

(In reply to comment #0)

> On a side note - leaving IO barriers on and turning off journals on ext4,
> returned performance back to the numbers seen with barriers off.

I think this is perfectly expected, because only JBD2 issues barrier IO directly; other barriers come from blkdev_issue_flush in the sync paths, but:

ext4_sync_file()
{
        ...

        if (!journal)
                return simple_fsync(file, dentry, datasync);

        ...

        if (jbd2_log_start_commit(journal, commit_tid))
                jbd2_log_wait_commit(journal, commit_tid);
        else if (journal->j_flags & JBD2_BARRIER)
                blkdev_issue_flush(inode->i_sb->s_bdev, NULL);
        return ret;
}

we do not ever get that far if we don't have a journal.  IOW, "barriers on" with no journal is a no-op.

-Eric

I also noticed that the DB2 data files grow during the run as opposed to other databases like Sybase and Oracle which fully pre-allocate the data files. This results in very little meta data modifications during the actual run on Oracle and Sybase compared to DB2.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

It would be interesting to see if DB2 can support better pre-allocation and if so, that might be a quick term work around.

Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
For now we will need to document (if not already done) that enterprise-class storage should be mounted with -o nobarrier.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-For now we will need to document (if not already done) that enterprise-class storage should be mounted with -o nobarrier.+Enterprise-class storage should always be mounted with using the -o nobarrier option

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,5 @@
-Enterprise-class storage should always be mounted with using the -o nobarrier option+The Linux barrier mount option allows file systems to run safely on storage devices that have an enabled, non-battery backed write cache.  For example, local S-ATA or SAS disks with write cache enabled will need to run with barriers in order to survive a system outage or crash.
+
+File systems that live on top of high end storage, for example an external disk array or internal hardware RAID card with internal battery support, do not benefit or need this.
+
+For this second class of devices, the file system should be mounted with "-o nobarrier" as a mount option.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

I think that this has been resolved with 6.1 with our updated barrier patches.

Sanjay, do you still see this huge loss with DB2 and barriers? If not, we should close this as fixed in 6.1.

Thanks!

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This is fixed by the patches from 657046.

*** This bug has been marked as a duplicate of bug 657046 ***