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?
(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...)
Hmmm... is store ordering what you're looking for? Eg
make sure that in the case of power failure, all previous writes
will be visible after reboot if any subsequent write are visible.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
