> 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). > . 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. > hese are both bugs in ZFS and will be fixed.
That´s it! It´s 100% for me! ;-) One is the "all-or-nothing" problem, and the other is about guilty... ;-)) > > 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]. In my opinion would be great the whole functionality in zdb. it´s simple, and the concepts are clear on the tool. mdb is a debugger, needs concepts that i think is different in a tool for read/fix filesystems. Just an opinion... What does not mean we can not have both. Like i said, flexibility, options... ;-) But I haven't actually heard a reasonable > proposal for what a > fsck-like tool I think we must NOT stuck in the word "fsck", i have used it just as an example (Lost and Found). And i think other users used just as an example too. The important is the two points you have described very *well*. (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-remove > d-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-discu > ss Many thanks for your answer! Leal. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
