From owner-freebsd-fs Sat Oct 12 8:22:32 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 010CF37B401 for ; Sat, 12 Oct 2002 08:22:29 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient80-218-16-13.hispeed.ch [80.218.16.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A14DB43E42 for ; Sat, 12 Oct 2002 08:22:27 -0700 (PDT) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from MAIL.NetScum.DynDNS.dK (ipv6.NetScum.dyndns.dk [2002:50da:100d:0:250:daff:fe21:edca]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id g9CFMM700456 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sat, 12 Oct 2002 17:22:23 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by MAIL.NetScum.DynDNS.dK (8.11.6/SMI-4.1-R00T0WNED) id g9CFMMt00455; Sat, 12 Oct 2002 17:22:22 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Sat, 12 Oct 2002 17:22:22 +0200 (CEST) Message-Id: <200210121522.g9CFMMt00455@MAIL.NetScum.DynDNS.dK> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave To: freebsd-fs@freebsd.org Subject: Re: UFS2 panic (and other issues) at mount with unusual `newfs' values X-Hacked: via telnet to your port 25, what else? References: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk> X-Internet-Access-Provided-By: CABAL MODEM (all hail CABAL) X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [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