Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de> writes:

> On Tue, Mar 09, 2004 at 08:29:02PM +0100, Juergen Hannken-Illjes wrote:
> > What is wrong with this little sequence of commands:
> > 
> > # newfs /dev/rraid3g
> > /dev/rraid3g: 46250.0MB (94720000 sectors) block size 65536, fragment size 8192
> >         using 15 cylinder groups of 3083.38MB, 49334 blks, 97792 inodes.
> > super-block backups (for fsck -b #) at:
> >       128,  6314880, 12629632, 18944384, 25259136, 31573888, 37888640, 44203392,
> >  50518144, 56832896, 63147648, 69462400, 75777152, 82091904, 88406656,
> > # fsck -f /dev/rraid3g
> > ** /dev/rraid3g
> > ** File system is already clean
> > ** Last Mounted on 
> > ** Phase 1 - Check Blocks and Sizes
> > ** Phase 2 - Check Pathnames
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > FREE BLK COUNT(S) WRONG IN SUPERBLK
> > SALVAGE? [yn] y
> > 
> > 1 files, 1 used, 5896830 free (14 frags, 737102 blocks, 0.0% fragmentation)
> > 
> > ***** FILE SYSTEM WAS MODIFIED *****
> 
> Ok, tried to understand this a little bit more and found this problem relies
> on the 64k/8k block/frag size:
> 
> 1) newfs creates a filesystem with a super block at 8k (bno 16) and
> 
> 	fs_sblkno == 8 and fs_sblockloc == 8192
> 
>    The value of fs_sblkno is WRONG.

I'm not convinced this is where the problem is.  Historically, the
SBOFF was always 8192 but the value of fs_sblkno is the location of
the alternate superblocks with respect to the start of each
cylinder group.

> 
> 2) The kernel uses and updates the super block at 8k (bno 16)
> 
> 3) fsck uses and updates the 1st alternate at 64k (bno 128)

The bug is probably in fsck if it is using this superblock
on an ffsv1 filesystem.  I'll take a closer look and see what
I think.

> 
> Everything works if set fs_sblkno = 16.
> 
> So what is wrong with this statement from newfs/mkfs.c:
> 
> 	sblock.fs_sblkno =
> 	    roundup(howmany(sblock.fs_sblockloc + SBLOCKSIZE, sblock.fs_fsize),
> 		sblock.fs_frag);

As I mentioned, I don't think the problem is this statement or in newfs.

> 	
> -- 
> Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Darrin