Date: Sun, 6 Jan 2002 03:42:32 +0100 (CET) From: BOUWSMA Beery <freebsd-user@netscum.dyndns.dk> To: freebsd-stable@freebsd.org Subject: panic with stable, probably fs-related Message-ID: <200201060242.g062gWn66370@beerswilling.netscum.dyndns.dk>
next in thread | raw e-mail | index | archive | help
[replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] Heh. I'm able to consistently crash -stable (built 22.dec) as a normal user by invoking `gpg', resulting in an integer divide fault while in kernel mode, etc. etc. etc. I haven't done much else as this `normal' user otherwise, so there are probably other programs that cause problems, because it appears to be the filesystem proper which is causing problems. (invoking gpg --homedir /tmp and invoking it as r00t both have no dire results, and I have the home directory of this user on some non-standard partition, intended for storage of huge files.) The 45GB disk partition holding the homedir in question reveals the following via `tunefs -p' tunefs: soft updates: (-n) enabled tunefs: maximum contiguous block count: (-a) 1 tunefs: rotational delay between contiguous blocks: (-d) 0 ms tunefs: maximum blocks per file in a cylinder group: (-e) 16384 tunefs: average file size: (-f) 67108864 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time (The value of `-f' was jacked way up when newfs'ing) The `disklabel' command reveals the following: 16 partitions: # size offset fstype [fsize bsize bps/cpg] h: 90194769 28573776 4.2BSD 16384 65536 2968 # (Cyl. 28347 - 117825*) (Note that I've fudged the number of MAXPARTITIONS to 16 which has otherwise caused no problems with anything else obvious) I don't remember exactly what I gave to newfs for this filesystem; one parameter (bsize?) wouldn't work if any larger, but I gave the maximum number bytes/inode that I could get away with, so that it looks like Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted /dev/ad0s3h 45095760 30978064 10510048 75% 108 3986 3% /usr/ho I know I've violated the suggested bsize/fsize=8 rule. Wonder if there's a 16-bit bsize floating around somewhere, he muses, having just hacked an i86 Minix program to work with numbers like 38400 This panic is very repeatable, and this is the first time I've invoked gpg, so it's trying to create its directory. I've had another -stable panic, which I haven't tried to repeat: when giving a series of commands to clean out empty directories like rmdir -p /usr/local/source-hacks/*/*/*/*/*/* but with more */*/* on the end, starting small and adding another for each invocation (softupdates fs): panic: newdirrem: inum 51220 should be 51210 I haven't tried to see if this is readily reproduced; I booted from the panicked -stable into -current to let background fsck clean up and there I had no problems cleaning out the rest of the empty directories. This fs isn't too abnormal, with the default 16384/2048 b/fsize, but with some symlinks hidden in the stars above (no damage could result since those pointed to a read-only fs). Like I say, after I pruned the directories under -current, I went on to other things thanks barry bouwmsa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201060242.g062gWn66370>