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 :)
FrankH.
(I do not actually have a use case for this on ZFS, since my experience with
ZFS is thus far limited to my home storage server. But I have wished for an
fbarrier() many many times over the past few years...)
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
