On 12-Feb-07, at 5:55 PM, Frank Hofmann wrote:
On Mon, 12 Feb 2007, Peter Schuller wrote:
Hello,
Often fsync() is used not because one cares that some piece of
data is on
stable storage, but because one wants to ensure the subsequent I/O
operations
are performed after previous I/O operations are on stable storage.
In these
cases the latency introduced by an fsync() is completely
unnecessary. An
fbarrier() or similar would be extremely useful to get the proper
semantics
while still allowing for better performance than what you get with
fsync().
My assumption has been that this has not been traditionally
implemented for
reasons of implementation complexity.
Given ZFS's copy-on-write transactional model, would it not be
almost trivial
to implement fbarrier()? Basically just choose to wrap up the
transaction at
the point of fbarrier() and that's it.
Am I missing something?
How do you guarantee that the disk driver and/or the disk firmware
doesn't reorder writes ?
The only guarantee for in-order writes, on actual storage level, is
to complete the outstanding ones before issuing new ones.
Or am _I_ now missing something :)
I'm no guru, but would not ZFS already require strict ordering for
its transactions ... which property Peter was exploiting to get
"fbarrier()" for free?
--Toby
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
