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.

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)

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);
	
-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)