Michael McCandless wrote:
Thanks for the numerous responses everyone! Responding to some of the
answers...:
ZFS has to trust the storage to have committed the data it
claims to have committed in the same way it has to trust the integrity
of the RAM it uses for checksummed data.
I hope that's not true.
Ie, I can understand that if an IO system "lies" in an fsync call
(returns before the bits are in fact on stable storage) that ZFS might
lose the pool. EG it seems like that may've been what happened on the
VB thread (though I agree since it was only the guest that crashed,
the writes should in fact have made it to disk, so...).
But if a bit flips in RAM, at a particularly unlucky moment, is there
any chance whatsoever that ZFS could lose the pool? There seems to be
mixed "opinions" here so far... but if I were tallying votes it looks
like more people say "no, it cannot" than "yes it may".
I've never seen reports of that happening. What I have seen is
corrupted files. Without checksums, the files would have been silently
corrupted.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
