Hi folks, Miles, I don't know if you have more information about this problem than I'm seeing, but from what Tom wrote I don't see how you can assume this is such a simple problem as an unclean shutdown?
Tom wrote "There was a problem with the SAS bus which caused various errors including the inevitable kernel panic". It's the various errors part that catches my eye, to me this means the SAS bus could have caused bad data to be written to disk for some time before the kernel panic, and that is far more serious to a filesystem than a simple power cut. Can fsck always recover a disk? Or if the corruption is severe enough, are there times when even that fails? I don't see that we have enough information here to really compare ZFS with UFS although I do agree that some kind of ZFS repair tool sounds like it would be useful. The problem for me is that I don't know enough about the low level stuff to really have an informed opinion on that. To me, it sounds like Sun have designed ZFS to always know if there is corruption on the disk, and to write data in a way that corruption of the whole filesystem *should* never happen. But I also feel that there are times that hardware can fail in strange ways, and there's always a chance that a pool could become corrupted due to hardware error in a way that prevents it being mounted. While I can see where Sun are coming from in that they've designed ZFS to engineer around these problems, and avoid the need to repair filesystems by using mirroring, multiple copies, etc. I do think a fsck like utility that can try to mount a failed system would be good for ZFS, it's certainly worth somebody who knows ZFS sitting down and thinking "how can we recover a pool if we know that X is corrupted", where X refers to any of the core pieces ZFS needs on its disk(s). Ross This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
