Date: Thu, 5 Sep 2002 06:24:49 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Daniel Rock <D.Rock@t-online.de> Cc: current@FreeBSD.ORG Subject: Re: fsck cannot find superblock Message-ID: <20020905053617.Q2728-100000@gamplex.bde.org> In-Reply-To: <3D765C1E.8040701@t-online.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Sep 2002, Daniel Rock wrote: > Bruce Evans schrieb: > > >On Tue, 3 Sep 2002, D. Rock wrote: > >>with 'uncommon' block sizes fsck seems to have problems finding the > >>superblock: > > > >fsck_ffs has no problems here with (whole) md disk of the same size. > >Perhaps I have fixed the problem without noticing. dumpfs or comparison > >with a non-broken filesystem of the same size might show the problem. > > The problem seems to be introduced with the UFS2 import. In > src/sbin/fsck_ffs/setup.c the sanity checks are more tightly formulated. > Especially one check was added: > sblock.fs_bsize >= SBLOCKSIZE > > this fails on 4K file systems, because fs_bsize is only 4096, but > SBLOCKSIZE is defined as 8192. The sanity checks for searching alternate Ah. In fact, I have fixed this without noticing that it was so broken. The sanity test is obviously insane, since the minimum block size (4K) has been smaller than the maximum superblock size (SBLOCKSIZE = 8K) forever. I reduced the minimum block size (MINBSIZE) to 512 some time ago and had to fix similar problems in the kernel. The ufs2 changes added similar problems in many utilities. > superblocks are more relaxed (in readsb() the first if branch is > entered, not the else branch), so during searching for alternate > superblocks the very same sb that was rejected in the first run (at > offset 8192) will be used. > > Possible solutions: > > * remove above sanity check > * does SBLOCKSIZE really have to be 8192, in real it is much smaller > (less than 2KB) The super block size is given by fs_sbsize, and newfs is happy to set it to much smaller than 8192. I tried to reduce it as much as possible. IIRC, it gets rounded up to a multiple of the block size, so it can be 4K but no smaller when the block size is 4K. It can be 1536 if the block block size is 512, but no smaller since sizeof(struct fs) is 1376. I think the removal of rotdelay stuff makes its size always the same as that of struct fs (rounded up). dumpfs output: %%% magic 11954 (UFS1) time Thu Sep 5 06:06:17 2002 id [ 3d7667b9 39a059fe ] ncg 9 size 8192 blocks 7475 bsize 512 shift 9 mask 0xfffffe00 ^^^^^^^^^^^ fsize 512 shift 9 mask 0xfffffe00 frag 1 shift 0 fsbtodb 0 minfree 8% optim time symlinklen 60 maxbpg 64 maxcontig 256 contigsumsize 16 nbfree 7474 ndir 1 nifree 2121 nffree 0 cpg 1 bpg 937 fpg 937 ipg 236 nindir 128 inopb 4 nspf 1 maxfilesize 1082202111 sbsize 1536 cgsize 512 cgoffset 0 cgmask 0xffffffff ^^^^^^^^^^^^ csaddr 108 cssize 512 rotdelay 0ms rps 60 trackskew 0 interleave 1 nsect 937 npsect 937 spc 937 sblkno 32 cblkno 48 iblkno 49 dblkno 108 cgrotor 0 fmod 0 ronly 0 clean 1 flags none %%% BTW, dumpfs's error handling has been broken by conversion to libufs. libufs in -current has slightly different insane sanity checks, and when these fail dumpfs prints "dumpfs: /dev/md0: No such file or directory" despite it just having opened and read from that file. It used to print "dumpfs: Cannot find filesystem superblock". > * drop support for 4K block sizes completely, but this breaks > backwards compatibility I use patches like the following for the sanity checks: %%% Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.38 diff -u -2 -r1.38 setup.c --- setup.c 21 Aug 2002 18:10:28 -0000 1.38 +++ setup.c 22 Aug 2002 01:36:30 -0000 @@ -316,6 +314,6 @@ numfrags(&sblock, sblock_try[i]))) && sblock.fs_ncg >= 1 && - sblock.fs_bsize >= SBLOCKSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_bsize <= MAXBSIZE && + sblock.fs_sbsize <= SBLOCKSIZE) break; } %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020905053617.Q2728-100000>