NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: state or future of LFS?


On Apr 10, 2009, at 12:01 PM, Miles Nordin wrote:
[ ... ]
POSIX guarantees no such thing, nor is any such thing implied by a working
version of POSIX's ``optional'' (ignored on Mac OS X) fsync() call.

Forgive me for nitpicking a single comment from an otherwise long and interesting post, but fsync() isn't ignored on OSX.

If one is using UFS / BerkeleyFFS filesystem, calling fsync() invokes buf_flushdirtyblks() from xnu/bsd/ufs/ffs/ffs_vnops.c and does not return until that completes because MNT_WAIT is set. If you're using HFS+ as the filesystem, fsync() similarly calls buf_flushdirtyblks() in xnu/bsd/hfs/hfs_vnops.c to scribble the data blocks and updates the metadata to the journal, but doesn't wait for the journal itself to be flushed to a fully written-to-disk state.

The HFS+ case is cheating a bit, admittedly, but if you want fsync() to an HFS+ filesystem to not return until the journal is also flushed, enable the following sysctl:

  sysctl -w kern.always_do_fullfsync=1

...or, databases and the like might use the following fcntl() command:

F_FULLFSYNC Does the same thing as fsync(2) then asks the drive to flush all buffered data to the permanent storage device (arg is ignored). This is currently implemented on HFS, MS-DOS (FAT), and Universal Disk Format (UDF) file systems. The operation may take quite a while to complete. Certain FireWire drives have also been known to ignore the request to flush their buffered data.

Of course, some ATA/SATA drives will also lie about whether they've actually written data to disk.


Home | Main Index | Thread Index | Old Index