On 10-Feb-09, at 7:41 PM, Jeff Bonwick wrote:
well....if you want a write barrier, you can issue a flush-cache and
wait for a reply before releasing writes behind the barrier. You
will
get what you want by doing this for certain.
Not if the disk drive just *ignores* barrier and flush-cache commands
and returns success. Some consumer drives really do exactly that.
That's the issue that people are asking ZFS to work around.
But it's important to understand that this failure mode (silently
ignoring SCSI commands) is truly a case of broken-by-design hardware.
If a disk doesn't honor these commands, then no synchronous operation
is ever truly synchronous -- it'd be like your OS just ignoring
O_SYNC.
This means you can't use such disks for (say) a database or NFS
server,
because it is *impossible* to know when the data is on stable storage.
This applies equally to virtual disks, of course (can we get
VirtualBox to NOT ignore flushes by default?)
--Toby
If it were possible to detect such disks, I'd add code to ZFS that
would simply refuse to use them. Unfortunately, there is no reliable
way to test the functioning of synchonize-cache programmatically.
Jeff
_______________________________________________
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
