disk recovery help

[Peter Jeremy]

On Mon, 2004-Jul-26 14:30:08 -0400, Charles Sprickman wrote:
>I did get confirmation from Adaptec that it does go from the outside
>sectors in.

In which case one of the first things to be over-written would have
been the first superblock and fsck should complain and stop immediately
if this is invalid.

>I ended up using sysutils/ffsrecov to grab the alternate superblocks.

Maybe that was the tool I was thinking of.

>I have a reasonably OK fsck'd filesystem mounted now.  I have another copy
>to work on, and my question there is this:  When you run fsck it creates a
>"lost+found" directory to put files that are unreferenced anywhere (I
>think that's the terminology).  At some point during the fsck, it starts
>spitting errors about there not being enough space in "lost+found".  Is
>there any way to remedy that problem?  Is there some way to "grow" the
>filesystem *before* fsck-ing it?

fsck will grow the lost+found directory if necessary but it can only
grow it to the limit of the direct blocks (12 filesystem blocks).  The
only way to pre-grow the lost+found directory would be to mount the
filesystem read/write, create a large number of (preferably large)
filenames and then delete them[1].  I'm not sure if the fsck code can
understand indirect blocks in the lost+found directory so I don't know
if this would work.  It also relies on the filesystem to be sane enough
for normal block allocation to work.

One option might be to force a read/write mount, rename lost+found,
umount the filesystem and redo the fsck until it fills the new
lost+found.  Renaming a directory entry is fairly safe, especially if
you don't change the entry size.  Alternatively, do this with fsdb -
which is definitely safe.

[1] Directories are only shrunk when an entry is created, not when one
    is deleted.

-- 
Peter Jeremy