--=-=-=


Does this (untested) patch solve the problem?  It only allows fsck to
find a ffsv1 superblock in the traditional location.

Darrin


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=fsck_ffs.diff
Content-Description: patch to only allow ffs1 superblock in ffs1 location

Index: src/sbin/fsck_ffs/setup.c
===================================================================
RCS file: /cvsroot/src/sbin/fsck_ffs/setup.c,v
retrieving revision 1.69
diff -u -u -p -r1.69 setup.c
--- src/sbin/fsck_ffs/setup.c	20 Jan 2004 15:29:35 -0000	1.69
+++ src/sbin/fsck_ffs/setup.c	10 Mar 2004 23:51:59 -0000
@@ -641,7 +641,10 @@ readsb(listerr)
 			    super, (long)SBLOCKSIZE) != 0)
 				continue;
 			fs = sblk.b_un.b_fs;
-			if (detect_byteorder(fs) == 0)
+			if ((detect_byteorder(fs) == 0) &&
+			    ((sblock_try[i] == SBLOCK_UFS1) ||
+			      ((fs->fs_magic != FS_UFS1_MAGIC) &&
+			       (fs->fs_magic != bswap32(FS_UFS1_MAGIC)))))
 				break;
 		}
 		if (sblock_try[i] == -1) {

--=-=-=



"Darrin B. Jewell" <dbj@NetBSD.org> writes:

> 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

--=-=-=--