Re: state or future of LFS?

[Chuck Swiger <cswiger%mac.com@localhost>]

Hi--

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.

Regards,
--
-Chuck