2007/2/12, Frank Hofmann <[EMAIL PROTECTED]>:
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.
This is true for NCQ with SATA, but SCSI also supports ordered tags,
so it should not be necessary.
At least, that is my understanding.
Chris
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
