> 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.
The GC operation is what I was referring to by a 'fsck'-like utility. (not that it has to be a stand-alone utility in the way fsck is). > 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. Understood. I was really just interested in learning if this was a "we wanted to get other stuff out the door first" or a "we're not sure it's possible" type problem. -- 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
