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". > > For example, if the wrong bit flips at the wrong time, could I lose my > > entire RAID-Z pool instead of, say, corrupting one file's contents or > > metadata? Is there such a possibility? > > Not likely, but I don't think anyone has done such low-level > analysis to prove it. So this is exactly what I'm driving at -- has there really been no such low level failure analysis? Ie, "if a bit error happens at point XYZ in ZFS's code, what's the impact" (for XYZ at all "interesting" points)? EG say (pure speculation) ZFS has a global checksum that's written on closing the pool, and then later the pool cannot be imported when the checksum is bad. Since a bit error could corrupt that checksum, this would in fact mean I could "lose" the pool due to an unluckily timed bit error. The decision (to use ECC or not) ought to be a basic cost/benefit analysis, once one has the facts. I'm trying to get to the facts here... ie, if you don't use ECC just how bad is it when bit errors inevitably happen? If the effects are local (file/dir contents & metadata get corrupted) that's one thing; if I could lose the pool that's very different. [Eventually] armed with the facts, one should be free to decide on ECC or not just like one picks, say, the latest & greatest consumer hard drive (higher risk of errors since they have no track record) or a known good enterprise hard drive. > You still have the processor to worry about though. and > NB many hard disk drives and controllers have only parity protected > memory. So even if your main memory is ECC, it is unlikely that the > entire data path is ECC protected. These are good points -- even if you have ECC RAM, your CPU and PCI bus and other parts of the data path could still flip bits. So I'm really hoping the answer is "no, you'll never lose the pool from bit errors". > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6667683 > > Most of the issues that I've read on this list would have been > "solved" if there was a mechanism where the user / sysadmin could tell > ZFS to simply go back until it found a TXG that worked. This one sounds important! Any means of disaster recovery would be very welcome... BTW is there some way for a user to vote/comment on bugs? EG I think I've hit this one: http://bugs.opensolaris.org/view_bug.do?bug_id=6807184 And would love to vote, share my config, situation, etc. But I can't find any links that let me, there are no comments on the bug, etc. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
