disk recovery help

[Charles Sprickman]

On Thu, 22 Jul 2004, Peter Jeremy wrote:

> >command does, but they are fairly certain that it writes it's config at
> >the end of the disk, then zeros it from the outside in.
>
> Which puts an upper limit on the amount of damage done.  The only
> difficulty with this is that (ISTR) your filesystem begins at the
> beginning of the array so the primary superblock should be the first
> thing over-written - and fsck would whinge loudly about that.

I did get confirmation from Adaptec that it does go from the outside
sectors in.

> >grabbed the dd "image" before that.  An fsck on the problem partition ran
> >for 12 hours and I don't know how far along it was.
>
> Ctrl-T (aka SIGINFO) is your friend - fsck will tell you how far
> through its current phase it is.

Ah.  Hence the reference to stty in the fsck manpage.  Thanks!

> I was hoping it would also locate all the superblocks - which
> would let you verify that the structure looked reasonably sane.

> You might also try fsdb(8) - though I think it relies on the primary
> superblock being sane.

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

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?

The only bit about this in the fsck manpage is the following:

"If the lost+found directory does not exist, it is created.  If there is
insufficient space its size is increased."

Thanks to everyone for your help so far.  This has been a good learning
experience.

Charles

> Good luck.
>
> --
> Peter Jeremy
>