Date: Thu, 7 Nov 2002 16:48:43 +0100 (CET) From: BOUWSMA Beery <freebsd-misuser@ipv6.netscum.dyndns.dk> To: freebsd-fs@freebsd.org Subject: B0rken -current handling of UFS1 filesystems with 64k block size... Message-ID: <200211071548.gA7Fmhl00515@MAIL.NetScum.DynDNS.dK>
next in thread | raw e-mail | index | archive | help
[IPv6-only address above; strip the obvious for IPv4-only mail] Howdy y'all, I'm trying to track down why many parts of -current seem to have been broken when handling filesystems I've been successfully using with -stable (and with ancient -current), that I created with 64k block size. It seems that dumpfs (in particular, since it's easiest to try) worked fine as of 19.Jun (before the UFS2 commit) based on a binary found on current.freeebsd.org, while 07.Jul binary (one of only a few available before the libufs commit) fails just as a binary from today. It appears that that since 21.Jun (the UFS2 commit), the search for a superblock happens first at a location 64k into the disk (default UFS2 location), then at 8k (original UFS1 location), then at the beginning (floppies), then at 256k (piggy location)? That's what ufs/ffs/fs.h implies to me. If I have a UFS1 filesystem that I created with 64k block size, is it possible that in addition to the real superblock at 8k, there is an alternate superblock, or something similar, at 64k, which is found, but which does not have the up-to-date data, which confuses dumpfs, fsck, df, and who knows what all, under -current? In fact, adding debugging to libufs/sblock.c indicates that the bogus superblock info I see is found by the search at a 64k offset, and that by ignoring this data, I get the proper data when the search continues at the 8k offset. If this is true, explaining the difference in `ndir' and free inodes and date and so on between the -current and -stable `dumpfs' output, maybe something like a sanity check that at 64k, it really is a UFS2 magic superblock that is found, else skip to the next check at 8k or wherever for the UFS1 superblock... Or something -- not sure what. (maybe there are issues, like specifying an alternate superblock location to fsck, that would preclude this, but a quick look showed me that the problematic fsck didn't even seem to use libufs in recent -current. maybe there are also problems with a real superblock offset for floppy at 0, and something at 8k?) I will happily post info about the problems I've observed, which can be readily reproduced under -current by creating a new filesystem as UFS1 with -b blocksize of 65536, after which -current's `fsck' complains that numdir is zero, and the output of `dumpfs' differs greatly from that of -stable, and mounting the `newfs'ed filesystem and checking with `df' shows zero inodes or space used, even after filling the disk under -stable (don't remember if filling under -current worked or if I tried). These filesystems *seem* to have no problems (at least nothing significant) when created by -current but used by -stable. Just ask me for the detailed message I composed before deciding to try to track this down first before posting. 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?200211071548.gA7Fmhl00515>