Frank Middleton wrote:
Finally, a number of posters blamed VB for ignoring a flush, but
according to the evil tuning guide, without any application syncs,
ZFS may wait up to 5 seconds before issuing a synch, and there
must be all kinds of failure modes even on bare hardware where
it never gets a chance to do one at shutdown. This is interesting
if you do ZFS over iscsi because of the possibility of someone
tripping over a patch cord or a router blowing a fuse. Doesn't
this mean /any/ hardware might have this problem, albeit with much
lower probability?
No. You'll lose unwritten data, but won't corrupt the pool, because the on-disk
state will be sane, as long as your iSCSI stack doesn't lie about data commits
or ignore cache flush commands. Why is this so difficult for people to
understand? Let me create a simple example for you.
Get yourself 4 small pieces of paper, and number them 1 through 4.
On piece 1, write "Four" (app write disk A)
On piece 2, write "Score" (app write disk B)
Place piece 1 and piece 2 together on the side (metadata write, cache flush)
On piece 3, write "Every" (app overwrite disk A)
On piece 4, write "Good" (app overwrite disk B)
Place piece 2 and piece 3 on top of pieces one and 2 (metadata write, cache
flush)
IFF you obeyed the instructions, the only things you could ever have on the side
are nothing, "Four Score", or "Every Good" (we assume that side placement is
atomic). You could get killed after writing something on pieces 3 or 4, and lose
them, but you could never have garbage.
Now if you were too lazy to bother to follow the instructions properly, we could
end up with bizarre things. This is what happens when storage lies and re-orders
writes across boundaries.
--
Carson
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
