Re: fsck_ufs: cannot alloc 3166749884 bytes for inoinfo

On 10 Apr, Thomas Klausner wrote:
> On Sun, Feb 27, 2005 at 08:24:15AM +0000, Don Lewis wrote:
>> On 26 Feb, Kris Kennaway wrote:
>> > A recent panic left my FS with some serious corruption, which fsck is
>> > unable to repair:
>> > 
>> > # fsck_ufs -b 376512 -fy /var
>> > Alternate super block location: 376512
>> > ** /dev/twed0s1e
>> > ** Last Mounted on
>> > ** Phase 1 - Check Blocks and Sizes
>> > fsck_ufs: cannot alloc 3166749884 bytes for inoinfo
>> > 
>> > (same holds for any superblock I've tried).
>> > 
>> > How can I recover from this, short of running newfs?
>> 
>> What does dumpfs say about the contents of the superblock?  For some
>> reason fsck thinks it needs to allocate space to hold the information
>> about 791687471 in one cylinder group, which seems a bit unlikely.
> 
> I have a similar problem with a 110GB UFS on 5.3/i386.
> fsck dies for me with:
> fsck_ufs: cannot alloc 607016868 bytes for inoinfo
> 
> df output is strange too:
> /dev/ad6s1a 113552318 -6315512682 6419980816 -6045%    /vcr
> 
> The dumpfs output for the file system is attached;
> As you can see, dumpfs dumps core in the end.
> 
> Any ideas how to restore this file system without using newfs
> are welcome.

At line 92 in src/sbin/fsck_ffs/pass1.c, you should see the following
block of code:

        for (c = 0; c < sblock.fs_ncg; c++) {
                inumber = c * sblock.fs_ipg;
                setinodebuf(inumber);
                getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize);
                if (sblock.fs_magic == FS_UFS2_MAGIC)
                        inosused = cgrp.cg_initediblk;
                else
                        inosused = sblock.fs_ipg;

Try changing
	inosused = cgrp.cg_initediblk;
to
	inosused = (cgrp.cg_initediblk <= sblock.fs_ipg) ?
	    cgrp.cg_initediblk : sblock.fs_ipg;

and don't use the preen option.

I'm not sure what the correct way of handling this problem is, but
silently ignoring it probably is not right.  It would also be nice to
figure out how cg_initediblk is getting stomped on.  Your dumpfs output
shows that the cg 448 cylinder group block is getting spammed.

cg 448:^M
magic   5af7bc9b        tell    1419718000      time    Sat Oct 24 09:26:01 1953
^M
cgx     1974102781      ndblk   94980298        niblk   -238122138      initiblk
 151754217^M
nbfree  260006838       ndir    -1408502548     nifree  -1954530115     nffree
1098493286^M
rotor   -2054137791     irotor  264831483       frotor  -828630751^M
frsum   348903779       -1401240352     380969914       -1562381953     -1776938
457     90294057        -1759202067^M

Even the magic number is getting spammed (the correct value is 90255).
That would seem to be fatal in the preen case:

                if (preen && usedsoftdep) {
                        if (!cg_chkmagic(&cgrp))
                                pfatal("CG %d: BAD MAGIC NUMBER\n", c);