Note that there are two common reasons to have a fsck-like utility - 1. Detect corruption 2. Repair corruption
For the first, we have scrubbing (and eventually background scrubbing) so it's pointless in the ZFS world. For the latter, the type of things it repairs are known pathologies endemic to the underlying filesystem. For example, it knows how to reconnect inodes if you were in the middle of adding the corresponding directory entry, fixing up the global inode table, etc. For the type of corruption we're talking about, there is no repair procedure, period. We cannot deal with arbitrary corruption any more than other filesystems. However, we do have the advantage of always knowing when something is corrupted, and knowing what that particular block should have been. The best we can hope for is a) to identify orphaned blocks resulting from corruption and b) provide a way to move/free these files so they don't permanently pollute the filesystem namespace. - Eric On Thu, Jul 20, 2006 at 03:34:07PM -0500, Al Hopper wrote: > On Thu, 20 Jul 2006, Darren Dunham wrote: > > > > Well the fact that it's a level 2 indirect block indicates why it can't > > > simply be removed. We don't know what data it refers to, so we can't > > > free the associated blocks. The panic on move is quite interesting - > > > after BFU give it another shot and file a bug if it still happens. > > > > What's the long term solution for this type of corruption? Will there > > be a 'fsck'-like utility that can find all valid items and make sure > > they're connected properly, or is something else possible? > > This is deja vu and positively scary. In the bad old days, when we were > cursed with hierarchical databases[1], one ran the DB "fsck" equivalent. > And sometimes it worked; and sometimes it did'nt. And sometimes there > were bugs in the hierarchical fsck/repair utility that could turn your > minor DB "issue" into a totally trashed DB! :( > > We still have hierarchical databases of course - but todays software > technology and practices have made them far less vulnerable to nasty bugs. > Try running the test suite for the SleepyCat DB sometime you have a > machine you want to exercise... > > ZFS has a very reasonable tree-like data structure - but ... the memory > of hierarchical DB fsck-like utilities really scare me... There has to be > a better way. > > [1] and there were few alternatives. > > Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] > Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT > OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 > OpenSolaris Governing Board (OGB) Member - Feb 2006 > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
