Borys Saulyak wrote: >> Suppose that ZFS detects an error in the first >> case. It can't tell<br> >> the storage array "something's wrong, please >> fix it" (since the<br> >> storage array doesn't provide for this with >> checksums and intelligent<br> >> recovery), so all it can do is tell the user >> "this file is corrupt,<br> >> recover it from backups".<br> >> > Just to remind you. System was working fine with no sign of any failures. > Data got corrupted at export operation. If storage was somehow misbehaving I > would expect ZFS to complain about it on any operation which did not finish > succesfully.
From what I can predict, and *nobody* has provided any panic messages to confirm, ZFS likely had difficulty writing. For Solaris 10u5 and previous updates, ZFS will panic when writes cannot be completed successfully. This will be clearly logged. For later releases, the policy set in the pool's failmode property will be followed. Or, to say this another way, the only failmode property in Solaris 10u5 or NV builds prior to build 77 (October 2007) is "panic." For later releases, the default failmode is "wait," but you can change it. > I had NONE issues on the system with quite extensive read/write activity. > System panicked on export and messed everything such that pools could not be > imported. At what moment ZFS whould do better if I had even raid1 > configuration? I assume that this mess would be written on both disks and how > this would help me in recovering. I do understand that having more disks > would be better in case of failure of one or several of them. But only if > it's related to disks. I'm almost sure disks were fine during failure. Is > there anything you can improve apart from ZFS to cope with such issues? > > I think that nobody will be able to pinpoint the cause until someone looks at the messages and fma logs. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
