Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can force correct write ordering, using disk
flush cache commands.
After all that effort, I was very surprised to notice that Linux 2.6.x
doesn't use that capability to ensure fsync() flushes the disk cache
onto stable storage.
It's surprising you are surprised, given that this [lame] fsync behavior
has remaining consistently lame throughout Linux's history.
[snip huge long proposal]
Rather than invent new APIs, we should fix the existing ones to _really_
flush data to physical media.
Linux should default to SAFE data storage, and permit users to retain
the older unsafe behavior via an option. It's completely ridiculous
that we default to an unsafe fsync.
And [anticipating a common response from others] it is completely
irrelevant that POSIX fsync(2) permits Linux's current behavior. The
current behavior is unsafe.
Safety before performance -- ESPECIALLY when it comes to storing user data.
Regards,
Jeff (Linux ATA driver dude)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
