On Fri, Oct 10, 2008 at 06:15:16AM -0700, Marcelo Leal wrote: > - "ZFS does not need fsck". > Ok, that?s a great statement, but i think ZFS needs one. Really does. > And in my opinion a enhanced zdb would be the solution. Flexibility. > Options.
About 99% of the problems reported as "I need ZFS fsck" can be summed up by two ZFS bugs: 1. If a toplevel vdev fails to open, we should be able to pull information from necessary ditto blocks to open the pool and make what progress we can. Right now, the root vdev code assumes "can't open = faulted pool," which results in failure scenarios that are perfectly recoverable most of the time. This needs to be fixed so that pool failure is only determined by the ability to read critical metadata (such as the root of the DSL). 2. If an uberblock ends up with an inconsistent view of the world (due to failure of DKIOCFLUSHWRITECACHE, for example), we should be able to go back to previous uberblocks to find a good view of our pool. This is the failure mode described by Jeff. These are both bugs in ZFS and will be fixed. The other 1% of the complaints are usually of the form "I created my pool on top of my old one" or "I imported a LUN on two different systems at the same time". It's unclear what a 'fsck' tool could do in this scenario, if anything. Due to a variety of reasons (hierarchical nature of ZFS, variable block sizes, RAIDZ-Z, compression, etc), it's difficult to even *identify* a ZFS block, let alone determine its validity and associate it in some larger construct. There are some interesting possibilities for limited forensic tools - in particular, I like the idea of a mdb backend for reading and writing ZFS pools[1]. But I haven't actually heard a reasonable proposal for what a fsck-like tool (i.e. one that could "repair" things automatically) would actually *do*, let alone how it would work in the variety of situations it needs to (compressed RAID-Z?) where the standard ZFS infrastructure fails. - Eric [1] http://mbruning.blogspot.com/2008/08/recovering-removed-file-on-zfs-disk.html -- Eric Schrock, Fishworks http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
