From: Richard Elling <[EMAIL PROTECTED]> Miles Nordin wrote: >>>>>> "re" == Richard Elling <[EMAIL PROTECTED]> writes: >>>>>> "tb" == Tom Bird <[EMAIL PROTECTED]> writes: >>>>>> > ... > > re> In general, ZFS can only repair conditions for which it owns > re> data redundancy. tb> If that's really the excuse for this situation, then ZFS is not tb> ``always consistent on the disk'' for single-VDEV pools.
re> I disagree with your assessment. The on-disk re> format (any on-disk format) necessarily assumes re> no faults on the media. The difference between ZFS re> on-disk format and most other file systems is that re> the metadata will be consistent to some point in time re> because it is COW. ... tb> There was no loss of data here, just an interruption in the connection tb> to the target, like power loss or any other unplanned shutdown. tb> Corruption in this scenario is is a significant regression w.r.t. UFS: re> I see no evidence that the data is or is not correct. ... re> However, I will bet a steak dinner that if this device re> was mirrored to another, the pool will import just fine, re> with the affected device in a faulted or degraded state. tb> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-June/048375.html re> I have no idea what Eric is referring to, and it does re> not match my experience. We had a similar problem in our environment. We lost a CPU on the server, resulting in metadata corruption and an unrecoverable pool. We were told that we were seeing a known bug that will be fixed in S10u6. http://mail.opensolaris.org/pipermail/zfs-discuss/2008-April/046951.html From: Tom Bird <[EMAIL PROTECTED]> tb> On any other file system though, I could probably kick tb> off a fsck and get back most of the data. I see the tb> argument a lot that ZFS "doesn't need" a fsck utility, tb> however I would be inclined to disagree, if not a tb> full on fsck then something that can patch it up to the tb> point where I can mount it and then get some data off or tb> run a scrub. If not that, then we need some sort of recovery tool. We ought to be able to have some sort of recovery mode that allows us to read off the known good data or roll back to a snapshot or something. When you have a really big file system, telling us (as Sun support told us) that our only option was to re-build the zpool and restore from tape, it becomes really difficult to justify using the product in certain production environments. (For example, consider an environment where the available storage is on a hardware RAID-5 system, and where mirroring large amounts of already RAID-ed space adds up to more cost than a VxFS license. Not every type of data requires more protection than you get with standard hardware-based RAID-5.) --Scott This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
