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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
