fsck and mount disagree on whether superblocks are usable

[Martin Cracauer]

Julian H. Stacey wrote on Mon, Feb 04, 2008 at 10:04:47PM +0100: 
> Martin Cracauer wrote:
> > Julian H. Stacey wrote on Mon, Feb 04, 2008 at 06:27:14PM +0100: 
> > > Martin Cracauer wrote:
> > > > Julian H. Stacey wrote on Sat, Feb 02, 2008 at 08:16:30PM +0100: 
> > > > > Martin Cracauer wrote:
> > > > > > This is not an emergency but I find it odd.  Mount and fsck agree on
> > > > > > whether superblocks are usable.  Mount can mount readonly, but fsck
> > > > > > can use neither the primary superblock nor the alternatives.
> > > > > > 
> > > > > > 32 is not a file system superblock
> > > > > 
> > > > > Just in case, You know secondary block on newer FSs moved from 32 ?
> > > > > Ref man fsck_ufs
> > > > >    -b      Use the block specified immediately after the flag as the super
> > > > >              block for the file system.  An alternate super block is usually
> > > > >              located at block 32 for UFS1, and block 160 for UFS2.
> > > > 
> > > > Thanks, Julian.
> > > > 
> > > > I'm honestly don't know how to tell whether I have ufs1 or ufs2.
> > > 
> > > I didnt either, but wanted to know & just found one way:
> > > 
> > > dumpfs /dev/____ | grep -i ufs
> > 
> > Yupp, there you go.
> 
> > The reason why it failed for me is that it was looking for the
> > superblocks in the wrong place. 
> > 
> > This works:
> > fsck_ffs -b 160 /dev/ad0s1a
> > 
> > I now need to debug why the target machine's fsck seemed to think it's
> > ufs1 or why else it looked at 32 when the source machine didn't.
> 
> Yup, always nice to understand whats going on/went on, but at some
> stage in your shoes, I'd copy all data to another place & then newfs
> & copy back, for peace of mind :-)

Why do you say that?

`df -i` shows I only lost about 50,000 files :-)

~(grisu)1% df -i /
Filesystem  1024-blocks     Used    Avail Capacity iused    ifree %iused  Mounted on
/dev/ad0s1a   137150084 91580772 34597306    73%  976369 16758285    6%   /

~(wings)11# df -i /mnt/tmp
Filesystem  1024-blocks     Used    Avail Capacity iused    ifree %iused  Mounted on
/dev/ad0s1a   137150084 88153916 38024162    70%  932371 16802283    5%   /mnt/tmp


I still want to find out what's going on here.  The disk geometry as
reported by both fdisk and disklabel is identical, so that's not it.
I don't see the reason why fsck should get confused here and I think
that people might get bitten by this phaenomen after doing something
less insane than I did.

Basically, a 7-stable fsck destroyed a 6-stable filesystem here in a
situation where it might or might not be justified.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer at cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/