See: http://www.opensolaris.org/jive/thread.jspa?threadID=11305&tstart=0
Basically, the first step is to identify the file in question so the user knows what's been lost. The second step is a way to move these blocks into pergatory, where they won't take up filesystem namespace, but still account for used space. The final step is to actually delete the blocks and then do a garbage-collection type of operation to find which blocks are no longer referenced. This is a hugely complicated task, as dealing with snapshots and DMU accounting is going to be horrific, if possible at all. It is, however, on our (rather long) list of things to tackle. If your corruption is in a L0 data block, you're in a much better situation, because we know the size of the block and can safely free it without worrying about what else it might reference. - Eric On Thu, Jul 20, 2006 at 01:20:23PM -0700, 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? > > -- > Darren Dunham [EMAIL PROTECTED] > Senior Technical Consultant TAOS http://www.taos.com/ > Got some Dr Pepper? San Francisco, CA bay area > < This line left intentionally blank to confuse you. > > _______________________________________________ > 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
