[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
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.
Main Index |
Thread Index |