[OpenAFS-devel] to fsync() or not to fsync()

Robert Banz banz@umbc.edu
Thu, 14 Sep 2006 10:16:12 -0400


Unless you're somehow just "making the bits go faster", performance  
increases typically go hand in hand with some sort of risk that your  
transactions *might* not make it to disk in a "power off" situation*

* disk gets unplugged, machine panics, blahblah

...which is a "risk" almost any filesystem or application takes into  
consideration, and allows the filesystem user to determine when it's  
"really necessary" to wait to go forward until data is committed to  
firm storage, or not.  Good or bad, the fileserver is assuming that's  
what you want to do all of the time in the CopyOnWrite and  
StoreData_RXStyle (not to mention the volume structure management  
code in namei_ops, etc.).  I guess it's that since we don't have a  
"channel" to forward along real fsync() messages that we assume that  
it's what you want to do all the time, or at the time the code was  
written it was assumed horrible things were going to happen all of  
the time... cleaning lady unplugs the direct attached SCSI disk,  
cosmic ray causes a kernel panic, fsck can't reconstruct the  
filesystem to save it's life...  so making sure every transaction was  
written to disk was probably a good idea.  Nowadays with the cleaning  
lady banned from the datacenter unless escorted, multipathing fibre  
links to disk storage, filesystems that go beyond even metadata  
logging to preserve structure (like zfs), the cost/benefit of  
fsync'in is a much different discussion than it was a few years ago.

Anyhow, just my thoughts...  Perhaps we can make this optional, with  
the -go-faster option to fileserver & volserver? ;)

-rob