Marco Colombo wrote: > Ron Mayer wrote: >> Greg Smith wrote: >>> There are some known limitations to Linux fsync that I remain somewhat >>> concerned about, independantly of LVM, like "ext3 fsync() only does a >>> journal commit when the inode has changed" (see >>> http://kerneltrap.org/mailarchive/linux-kernel/2008/2/26/990504 ).... >> I wonder if there should be an optional fsync mode >> in postgres should turn fsync() into >> fchmod (fd, 0644); fchmod (fd, 0664); 'course I meant: "fchmod (fd, 0644); fchmod (fd, 0664); fsync(fd);" >> to work around this issue. > > Question is... why do you care if the journal is not flushed on fsync? > Only the file data blocks need to be, if the inode is unchanged.
You don't - but ext3 fsync won't even push the file data blocks through a disk cache unless the inode was changed. The point is that ext3 only does the "write barrier" processing that issues the FLUSH CACHE (IDE) or SYNCHRONIZE CACHE (SCSI) commands on inode changes, not data changes. And with no FLUSH CACHE or SYNCHRONINZE IDE the data blocks may sit in the disks cache after the fsync() as well. PS: not sure if this is still true - last time I tested it was nov 2006. Ron - Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
