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
