Description of problem: fsync() on a ext3 filesystem does not flush disk caches. This influences data consistency, especially for database system like MySQL and PostgreSQL. This bug has been fixed in kernel patch 2.6.31 via commit 56fcad29d4b3cbcbb2ed47a9d3ceca3f57175417 Author: Jan Kara <jack> Date: Tue Sep 8 14:59:42 2009 +0200 ext3: Flush disk caches on fsync when needed In case we fsync() a file and inode is not dirty, we don't force a transaction to disk and hence don't flush disk caches. Thus file data could be just in disk caches and not on persistent storage. Fix the problem by flushing disk caches if we didn't force a transaction commit. It would be great if this important fix could be integrated into the RHEL 5.x kernel line (2.6.18) and made available in the next kernel errata. Kind regards, Andreas Luik
Agreed, we should probably have this. Note that the behavior is only in effect if barriers are turned on, which is still not the default upstream or in rhel5. -Eric
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-219.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html