Date: Sat, 12 Oct 2002 17:22:22 +0200 (CEST) From: BOUWSMA Beery <freebsd-misuser@ipv6.netscum.dyndns.dk> To: freebsd-fs@freebsd.org Subject: Re: UFS2 panic (and other issues) at mount with unusual `newfs' values Message-ID: <200210121522.g9CFMMt00455@MAIL.NetScum.DynDNS.dK> References: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[IPv6-only address above; strip the obvious for IPv4-only mail]
About three months ago, I bothered both this list and -current with
a message, and I've finally gotten around to taking a closer look at
it, keeping it in -fs this time. I wrote:
> It seems that any -f fsize value larger than 8192 given to `newfs'
> creates a UFS2 filesystem that causes a panic when mounted, even
> #15 0xc0297772 in ffs_mount (mp=0xc1918400, path=0xc1922180 "/mnt", data=---Can'
> t read userspace from dump, or kernel process---
Adding some debuggery makes it appear that the real crash occurs
in sys/ufs/ffs/ffs_vfsops.c in ffs_mountfs() right here:
/* XXX DEBUG */ printf("ffs_mountfs: checkpoint 9\n");
bcopy(bp->b_data, ump->um_fs, (u_int)fs->fs_sbsize);
/* XXX DEBUG */ printf("ffs_mountfs: checkpoint 10\n");
This should be line 690, plus or minus a few, in 14.Sep 1.190
revision of this (last one I tried to build).
First question: with UFS2, what should the values for sbsize
be, so I know if the above line is at fault, or if the numbers
I give below indicate a problem elsewhere, like in newfs or
something?
So, I was having some thoughts about sbsize, after looking at a
few messages about problems others had had, and then making a
dump of the filesystem I've newfs'ed but can't mount:
bash-2.05a# /FreeBSD-CURRENT/sbin/dumpfs /dev/ad2s1e
magic 19540119 (UFS2) time Fri Oct 11 19:18:03 2002
offset 2 id [ 3da707cb 453cdc9d ]
ncg 8 size 2513070 blocks 2513001
bsize 65536 shift 16 mask 0xffff0000
fsize 32768 shift 15 mask 0xffff8000
^^^^^
frag 2 shift 1 fsbtodb 6
minfree 0% optim space symlinklen 120
maxbsize 65536 maxbpg 8192 maxcontig 2 contigsumsize 2
nbfree 1256499 ndir 1 nifree 4093 nffree 2
bpg 174097 fpg 348194 ipg 512
nindir 8192 inopb 256 maxfilesize 36033195603132415
sbsize 32768 cgsize 65536 csaddr 12 cssize 0
^^^^^
sblkno 4 cblkno 6 iblkno 8 dblkno 12
cgrotor 0 fmod 0 ronly 0 clean 1
flags soft-updates
Using `gdb' on the earlier panic I had showed then the fsize and
sbsize values were both 16384. As noted, with fsize of 8192 I had
no problems.
Now, using dumpfs on a -stable-created filesystem, with which I've
had no problem, shows something different:
magic 11954 (UFS1) time Sat Oct 12 15:47:53 2002
id [ 3c2e1d34 7670e862 ]
ncg 8 size 2818586 blocks 2818485
bsize 65536 shift 16 mask 0xffff0000
fsize 16384 shift 14 mask 0xffffc000
^^^^^
frag 4 shift 2 fsbtodb 5
minfree 8% optim time symlinklen 60
maxbpg 16384 maxcontig 1 contigsumsize 0
nbfree 59237 ndir 5 nifree 3929 nffree 13
cpg 2968 bpg 94976 fpg 379904 ipg 512
nindir 16384 inopb 512 nspf 32 maxfilesize 2882479694122844
15
sbsize 8192 cgsize 65536 cgoffset 128 cgmask 0xffffffff
^^^^
csaddr 16 cssize 16384
rotdelay 0ms rps 60 trackskew 0 interleave 1
nsect 4096 npsect 4096 spc 4096
sblkno 4 cblkno 8 iblkno 12 dblkno 16
cgrotor 3 fmod 0 ronly 0 clean 0
flags soft-updates
In other words, is the problem in the bcopy() line, or something
that it works on, or is the problem in the filesystem I created
which gets an sbsize value larger than 8k?
Of course, if someone proposes a patch, I'll be happy to test it.
As mentioned earlier, it's trivial to invoke the panic with any
fs frag size larger than 8k, with UFS2. I haven't tried to see if
I can create a fs like the UFS1 above under -current, but that idea
occurred to me as a test just for fun.
thanks,
barry bouwsma
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210121522.g9CFMMt00455>