Date: Sun, 21 Jul 2002 09:14:34 +0200 (CEST) From: BOUWSMA Beery <freebsd-misuser@ipv6.netscum.dyndns.dk> To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: UFS2 panic (and other issues) at mount with unusual `newfs' values Message-ID: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk>
next in thread | raw e-mail | index | archive | help
[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 <return> to continue, or q <return> 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207210714.g6L7EYi00479>