Re: fsck cannot find superblock
On Thu, 5 Sep 2002, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >> * drop support for 4K block sizes completely, but this breaks > >> backwards compatibility > > > >I use patches like the following for the sanity checks: > > I think there may be other problems that are triggered by using <8k > blocks on -current too. Last time I tried 4k blocks (pre-UFS2), the > snapshot code would cause a panic when trying to allocate a single > 4k block to fit the 8k superblock (the machine then got stuck in a > reboot-fsck-panic cycle until interrupted and manually fsck'd). I sometimes run a simple benchmark which tests most combinations of block and fragment sizes starting with 4096-512. This didn't show anoy problems for 4k blocks either pre- or post-ufs2. But it doesn't test snapshots, actual ufs2 filesystems, or anything else that is newer than soft updates, or full filesystems... Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck cannot find superblock
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> * drop support for 4K block sizes completely, but this breaks >> backwards compatibility > >I use patches like the following for the sanity checks: I think there may be other problems that are triggered by using <8k blocks on -current too. Last time I tried 4k blocks (pre-UFS2), the snapshot code would cause a panic when trying to allocate a single 4k block to fit the 8k superblock (the machine then got stuck in a reboot-fsck-panic cycle until interrupted and manually fsck'd). Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck cannot find superblock
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)timeThu Sep 5 06:06:17 2002 id [ 3d7667b9 39a059fe ] ncg 9 size8192blocks 7475 bsize 512 shift 9 mask0xfe00 ^^^ fsize 512 shift 9 mask0xfe00 frag1 shift 0 fsbtodb 0 minfree 8% optim timesymlinklen 60 maxbpg 64 maxcontig 256 contigsumsize 16 nbfree 7474ndir1 nifree 2121nffree 0 cpg 1 bpg 937 fpg 937 ipg 236 nindir 128 inopb 4 nspf1 maxfilesize 1082202111 sbsize 1536cgsize 512 cgoffset 0 cgmask 0x csaddr 108 cssize 512 rotdelay 0msrps 60 trackskew 0 interleave 1 nsect 937 npsect 937 spc 937 sblkno 32 cblkno 48 iblkno 49 dblkno 108 cgrotor 0 fmod0 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 - 1.38 +++ setup.c 22 Aug 2002 01:36:30 - @@ -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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck cannot find superblock
Bruce Evans schrieb: >On Tue, 3 Sep 2002, D. Rock wrote: > > > >>with 'uncommon' block sizes fsck seems to have problems finding the >>superblock: >> >># newfs -i 10240 -b 4096 -f 512 /dev/ad1d >>Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group >>/dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 >> using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. >>super-block backups (for fsck -b #) at: >> 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, >> 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, >> 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, >> 733632, 759832, 786032, 812232, 838432 >># fsck /dev/ad1d >>** /dev/ad1d >>Cannot find file system superblock >> >>LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n >> >> > >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. > >Bruce > > I have attached the label of the offending disk and an output of a dumpfs on a freshly created file system with the following options: newfs -b 4096 -f 4096 /dev/ad1d newfs -b 8192 -f 8192 /dev/ad1d 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 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) * drop support for 4K block sizes completely, but this breaks backwards compatibility Daniel # /dev/ad1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 252 tracks/cylinder: 4 sectors/cylinder: 1008 cylinders: 2482 sectors/unit: 2501856 rpm: 4500 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] b: 462996 2038860 swap# (Cyl. 2022*- 2481*) c: 25018560unused0 0 # (Cyl.0 - 2481) d: 83886004.2BSD 512 4096 26200 # (Cyl.0 - 832*) e: 120 8388604.2BSD 2048 8192 48388 # (Cyl. 832*- 2022*) magic 11954 (UFS1)timeWed Sep 4 20:33:22 2002 id [ 3d7651f2 4b7c67bc ] ncg 8 size104857 blocks 103972 bsize 4096shift 12 mask0xf000 fsize 4096shift 12 mask0xf000 frag1 shift 0 fsbtodb 3 minfree 8% optim timesymlinklen 60 maxbpg 512 maxcontig 32contigsumsize 16 nbfree 103971 ndir1 nifree 27389 nffree 0 cpg 1 bpg 13681 fpg 13681 ipg 3424 nindir 1024inopb 32 nspf8 maxfilesize 4402345721855 sbsize 4096cgsize 4096cgoffset 0 cgmask 0x csaddr 114 cssize 4096 rotdelay 0msrps 60 trackskew 0 interleave 1 nsect 109448 npsect 109448 spc 109448 sblkno 4 cblkno 6 iblkno 7 dblkno 114 cgrotor 0 fmod0 ronly 0 clean 1 flags none cs[].cs_(nbfree,ndir,nifree,nffree): (13565,1,3421,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (13571,0,3424,0) (8980,0,3424,0) cylinders in last group 1 blocks in last group 9090 cg 0: magic 90255 tell6000timeWed Sep 4 20:33:22 2002 cgx 0 ncyl1 niblk 3424ndblk 13681 nbfree 13565 ndir1 nifree 3421nffree 0 rotor 0 irotor 0 frotor 0 frsum sum of frsum: 0 clusters 1-8: 0 0 0 0 0 0 0 0 clusters 9-15: 0 0 0 0 0 0 0 clusters size 16 and over: 1 clusters free: 116-13680 inodes used:0-2 blks free: 116-13680 cg 1: magic 90255 tell3577000 timeWed Sep 4 20:33:22 2002 cgx 1 ncyl1 niblk 3424ndblk 13681 nbfree 13571 ndir0 nifree 3424nffree 0 rotor 0 irotor 0 frotor 0 frsum sum of frsum: 0 clusters 1-8: 0 0 0 1 0 0 0 0 clusters 9-15: 0 0 0 0 0 0 0 clusters size 16 and over: 1 clusters free: 0-3, 114-13680 inodes used: blks free: 0-3, 114-13680 cg
Re: fsck cannot find superblock
On Tue, 3 Sep 2002, D. Rock wrote: > with 'uncommon' block sizes fsck seems to have problems finding the > superblock: > > # newfs -i 10240 -b 4096 -f 512 /dev/ad1d > Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group > /dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 > using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. > super-block backups (for fsck -b #) at: > 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, > 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, > 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, > 733632, 759832, 786032, 812232, 838432 > # fsck /dev/ad1d > ** /dev/ad1d > Cannot find file system superblock > > LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n 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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fsck cannot find superblock
Hi, with 'uncommon' block sizes fsck seems to have problems finding the superblock: # newfs -i 10240 -b 4096 -f 512 /dev/ad1d Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group /dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. super-block backups (for fsck -b #) at: 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, 733632, 759832, 786032, 812232, 838432 # fsck /dev/ad1d ** /dev/ad1d Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n If I type 'y' fsck will find an alternate superblock at 16 (not 32, as printed during newfs). The number of inodes, fragment size don't seem to have an impact, only block size. No problems with block size of 8192 though. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
