From owner-freebsd-fs Sun Jul 21 0:15: 1 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 5C03E37B400; Sun, 21 Jul 2002 00:14:42 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-144-23.hispeed.ch [217.162.144.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF5C43E42; Sun, 21 Jul 2002 00:14:39 -0700 (PDT) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from beerswilling.netscum.dyndns.dk (ipv6.NetScum.dyndns.dk [2002:d9a2:9017:0:200:c0ff:fefc:19aa]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id g6L7EYS00480 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 21 Jul 2002 09:14:37 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/SMI-4.1-R00T0WNED) id g6L7EYi00479; Sun, 21 Jul 2002 09:14:34 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Sun, 21 Jul 2002 09:14:34 +0200 (CEST) Message-Id: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: UFS2 panic (and other issues) at mount with unusual `newfs' values X-Hacked: via telnet to your port 25, what else? 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] [sent to both -current and the -fs list, for no particular reason] Howdy, -current as of about a day ago. Decided to make a monster UFS2 disk to see if it works. It seems that any -f fsize value larger than 8192 given to `newfs' creates a UFS2 filesystem that causes a panic when mounted, even read-only. This appears true for `-b 16384 -f 16384', `-b 32768 -f 16384', and `-b 65536' with both -f 16384 and 32768. Using a value of 8192 for -f with 65536 and 32768 for -b seems in most cases to create a filesystem I can use, regardless of what other parameters I give, so the mount-time panic can be readily repeated. First of all, `newfs' normally coredumps as I observed earlier when a too-large blocksize is given. As the case for a too-small blocksize and fragment size is detected and twiddled in mkfs.c now, I suggest that the same be done for too large, rather than dumping core. The following patch to src/sbin/newfs/mkfs.c can do this: --- mkfs.c-ORIG Fri Jul 19 18:58:40 2002 +++ mkfs.c Sun Jul 21 00:00:44 2002 @@ -196,10 +196,15 @@ if (sblock.fs_bsize < MINBSIZE) { printf("increasing block size from %d to minimum (%d)\n", sblock.fs_bsize, MINBSIZE); sblock.fs_bsize = MINBSIZE; } + if (sblock.fs_bsize > MAXBSIZE) { + printf("decreasing block size from %d to maximum (%d)\n", + sblock.fs_bsize, MAXBSIZE); + sblock.fs_bsize = MAXBSIZE; + } if (sblock.fs_bsize < sblock.fs_fsize) { printf("increasing block size from %d to fragment size (%d)\n", sblock.fs_bsize, sblock.fs_fsize); However, there's a problem, in that bsize, from which sblock.fs_bsize is obtained, has already been used to set a number of other values in newfs.c. So it's probably better to do the check at the time the value is supplied, by this patch to newfs/newfs.c: --- newfs.c-ORIG Fri Jun 21 23:24:53 2002 +++ newfs.c Sun Jul 21 07:12:49 2002 @@ -186,7 +186,8 @@ optarg); break; case 'b': - if ((bsize = atoi(optarg)) < MINBSIZE) + if ((bsize = atoi(optarg)) < MINBSIZE || + bsize > MAXBSIZE) errx(1, "%s: bad block size", optarg); break; case 'c': This, unfortunately, doesn't give a clue as to what the minimum and maximum permissible values are, but I didn't see a simple way of doing this without recomputing all the values (like maxcontig) that depend on bsize, after adjusting it. And speaking of which, since the value for sblock.fs_bsize can be adjusted (theoretically, in what used to be exit() statements long ago), I'm wondering how right it is that the uncorrected bsize gets used before correction to calculate other values. Hmmm. You'll see a result of this in the example I give below (for maxcontig) Still, it's possible to create a new filesystem without real problems, that panics upon mount (even read-only), using values that are theoretically within range, such as the following first commandline I used: /usr/local/obj/5.0-CURRENT/usr/src/sbin/newfs/newfs -U -N -O 2 -i 1549357135 -b 131072 -f 32768 -g 134217728 -h 128 -m 0 -o space /dev/ad2s1e Superficially, the new filesystem looked fine... decreasing block size from 131072 to maximum (65536) ^^^ [my first, but improper, hack] Maxcontig raised to 131072 ^^^ [should not happen, because of my improper hack] density reduced from 1549357135 to 44585039 /dev/ad2s1e: 156334.5MB (320172992 sectors) block size 65536, fragment size 32768 using 15 cylinder groups of 10881.06MB, 174097 blks, 512 inodes. with soft updates super-block backups (for fsck -b #) at: 256, 22284672, 44569088, 66853504, 89137920, 111422336, 133706752, 155991168, 178275584, 200560000, 222844416, 245128832, 267413248, 289697664, 311982080 [00:51:10]root@dastardly.newsbastards.org:~{520}# tunefs -p /dev/ad2s1e tunefs: soft updates: (-n) enabled tunefs: maximum contiguous block count: (-a) 2 tunefs: maximum blocks per file in a cylinder group: (-e) 16384 tunefs: average file size: (-f) 134217728 tunefs: average number of files in a directory: (-s) 128 tunefs: minimum percentage of free space: (-m) 0% tunefs: optimization preference: (-o) space # size offset fstype [fsize bsize bps/cpg] c: 320172993 0 unused 0 0 # (Cyl. 0 - 317631*) e: 320172993 0 4.2BSD 32768 65536 20514 # (Cyl. 0 - 317631*) But as soon as I attempt to mount the filesystem, read-only, *POW* instant panic. Details: panic: bwrite: buffer is not busy??? panic messages: --- panic: vm_fault: fault on nofault entry, addr: c2f9a000 syncing disks... panic: bwrite: buffer is not busy??? Uptime: 46m16s pfs_vncache_unload(): 1 entries remaining Dumping 72 MB #2 0xc01ec2e5 in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc022003f in bwrite (bp=0xc2a872c8) at /usr/src/sys/kern/vfs_bio.c:797 #4 0xc0221391 in vfs_bio_awrite (bp=0xc2a872c8) at /usr/src/sys/kern/vfs_bio.c:1637 #5 0xc01c725c in spec_fsync (ap=0xc6dd474c) at /usr/src/sys/fs/specfs/spec_vnops.c:403 #6 0xc01c6e4b in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:121 #7 0xc0299279 in ffs_sync (mp=0xc0a65600, waitfor=2, cred=0xc0a55e80, td=0xc0365a80) at vnode_if.h:463 #8 0xc022f0d0 in sync (td=0xc0365a80, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:127 #9 0xc01ebdc1 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254 #10 0xc01ec2e5 in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #11 0xc02a7b97 in vm_fault (map=0xc0834000, vaddr=3271139328, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259 #12 0xc02debc5 in trap_pfault (frame=0xc6dd4938, usermode=0, eva=3271139328) at /usr/src/sys/i386/i386/trap.c:747 #13 0xc02de741 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1050185728, tf_esi = -10238 27968, tf_ebp = -958576032, tf_isp = -958576284, tf_ebx = -1023836160, tf_edx = -1049891840, tf_ecx = 6144, tf_eax = -26357760, tf_trapno = 12, tf_err = 0, tf_e ip = -1070738998, tf_cs = 8, tf_eflags = 66070, tf_esp = -1047358696, tf_ss = 0} ) at /usr/src/sys/i386/i386/trap.c:445 #14 0xc02d16e8 in calltrap () at {standard input}:98 #15 0xc0297772 in ffs_mount (mp=0xc1918400, path=0xc1922180 "/mnt", data=---Can' t read userspace from dump, or kernel process--- ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:350 #16 0xc0229941 in vfs_mount (td=0xc1565840, fstype=0xc14c8ad0 "ufs", fspath=0xc1922180 "/mnt", fsflags=1, fsdata=0xbfbff090) at /usr/src/sys/kern/vfs_mount.c:944 #17 0xc0229156 in mount (td=0xc1565840, uap=0xc6dd4d14) at /usr/src/sys/kern/vfs_mount.c:709 #18 0xc02df199 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134809385, tf_esi = -1077939 888, tf_ebp = -1077939960, tf_isp = -958575244, tf_ebx = 0, tf_edx = 0, tf_ecx = -1077940224, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134524503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077940164, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1049 #19 0xc02d171d in syscall_with_err_pushed () at {standard input}:128 ---Can't read userspace from dump, or kernel process--- Here's a slightly cleaner dump, with different parameters used when doing the newfs... panic: vm_fault: fault on nofault entry, addr: c308a000 panic messages: --- panic: vm_fault: fault on nofault entry, addr: c308a000 syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1: dev:ad2s1e, flags:20000220, blkno:128, lblkno:128 giving up on 1 buffers Uptime: 32m50s pfs_vncache_unload(): 1 entries remaining Dumping 72 MB #3 0xc02a7b97 in vm_fault (map=0xc0834000, vaddr=3272122368, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259 #4 0xc02debc5 in trap_pfault (frame=0xc731b938, usermode=0, eva=3272122368) at /usr/src/sys/i386/i386/trap.c:747 #5 0xc02de741 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1047912448, tf_esi = -10228 44928, tf_ebp = -953042336, tf_isp = -953042588, tf_ebx = -1022853120, tf_edx = -1047557376, tf_ecx = 6144, tf_eax = -25067520, tf_trapno = 12, tf_err = 0, tf_e ip = -1070738998, tf_cs = 8, tf_eflags = 66070, tf_esp = -1048027536, tf_ss = 0} ) at /usr/src/sys/i386/i386/trap.c:445 #6 0xc02d16e8 in calltrap () at {standard input}:98 #7 0xc0297772 in ffs_mount (mp=0xc172a400, path=0xc1662300 "/mnt", data=---Can' t read userspace from dump, or kernel process--- ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:350 #8 0xc0229941 in vfs_mount (td=0xc16cef00, fstype=0xc14c8920 "ufs", fspath=0xc1662300 "/mnt", fsflags=1, fsdata=0xbfbff070) at /usr/src/sys/kern/vfs_mount.c:944 #9 0xc0229156 in mount (td=0xc16cef00, uap=0xc731bd14) at /usr/src/sys/kern/vfs_mount.c:709 #10 0xc02df199 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134809385, tf_esi = -1077939 920, tf_ebp = -1077939992, tf_isp = -953041548, tf_ebx = 0, tf_edx = 0, tf_ecx = ---Type to continue, or q to quit--- -1077940480, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134524503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077940196, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1049 #11 0xc02d171d in syscall_with_err_pushed () at {standard input}:128 ---Can't read userspace from dump, or kernel process--- (kgdb) Using fsize of 8192 with bsize of 65536 did *not* result in a panic, even with other values like [07:30:05]root@dastardly.newsbastards.org:~{512}# /usr/local/obj/5.0-CURRENT/us r/src/sbin/newfs/newfs -U -O 2 -i 14864463 -b 65536 -f 8192 -g 134217728 -h 12 8 -m 0 -o space /dev/ad2s1e /dev/ad2s1e: 156334.5MB (320172992 sectors) block size 65536, fragment size 8192 using 44 cylinder groups of 3628.00MB, 58048 blks, 256 inodes. with soft updates super-block backups (for fsck -b #) at: 256, 7430400, 14860544, 22290688, 29720832, 37150976, 44581120, 52011264, 59441408, 66871552, 74301696, 81731840, 89161984, 96592128, 104022272, 111452416, 118882560, 126312704, 133742848, 141172992, 148603136, 156033280, 163463424, 170893568, 178323712, 185753856, 193184000, 200614144, 208044288, 215474432, 222904576, 230334720, 237764864, 245195008, 252625152, 260055296, 267485440, 274915584, 282345728, 289775872, 297206016, 304636160, 312066304, 319496448 This one mounted fine, and seems to be about the `best' I can do at the moment. Yeah yeah yeah, I know the fine manpage sez The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce poor results. but I've used such values with UFS-not-2 with no real problems. If anyone's wondering about such a thing, when i attempt to mount this disk under -stable (without UFS2), it sees the original old UFS filesystem I had created several days ago on this disk as if the UFS2 filesystem never was created. Whether this might have anything to do with the panics I see, well, I thought I should mention that before doing the -O 2 UFS2 newfs'ing, I had created a normal filesystem, should that mean anything. And obviously, I won't be able to do anything with this UFS2 filesystem under -stable, yet... thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message