Le 26 juil. 09 à 01:34, Toby Thain a écrit :
On 25-Jul-09, at 3:32 PM, Frank Middleton wrote:On 07/25/09 02:50 PM, David Magda wrote:Yes, it can be affected. If the snapshot's data structure / record is underneath the corrupted data in the tree then it won't be able to bereached.Can you comment on if/how mirroring or raidz mitigates this, or tree corruption in general? I have yet to lose a pool even on a machine with fairly pathological problems, but it is mirrored (and copies=2). I was also wondering if you could explain why the ZIL can't repair such damage. 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?The problem is assumed *ordering*. In this respect VB ignoring flushes and real hardware are not going to behave the same.--Toby
I agree that noone should be ignoring cache flushes. However the path to corruption must involve some dropped acknowledged I/Os. The ueberblock I/O was issued to stable storage but the blocks it pointed to, which had reached the disk firmware earlier, never make it to stable storage. I can see this scenerio when the disk looses power but I don't see it with cutting power to the guest.
When managing a zpool on external storage, do people export the pool before taking snapshots of the guest ?
-r
Thanks _______________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
