From owner-freebsd-current Fri Oct 18 16:30:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B610637B409; Fri, 18 Oct 2002 16:30:56 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B54D43E65; Fri, 18 Oct 2002 16:30:56 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id g9INUs59098884; Fri, 18 Oct 2002 16:30:55 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200210182330.g9INUs59098884@beastie.mckusick.com> To: BOUWSMA Beery Subject: Re: Stupid UFS2 questions... Cc: Robert Watson , freebsd-current@FreeBSD.org In-Reply-To: Your message of "Fri, 18 Oct 2002 17:13:08 EDT." Date: Fri, 18 Oct 2002 16:30:54 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Date: Fri, 18 Oct 2002 23:06:53 +0200 (CEST) From: BOUWSMA Beery To: freebsd-current@freebsd.org Subject: Stupid UFS2 questions... [IPv6-only address above; strip the obvious for IPv4-only mail replies] In trying to track down a panic I had while mounting a newly-created UFS2 filesystem, I noted that the `newfs' k0de had changed somewhat from -stable to -current. Specifically, that which determines the value of `sbsize' which I'm guessing should be no larger than 8192 else mounts cause panics. Here are the relevant lines from the last time I built -stable (mkfs.c): 547 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 548 if (sblock.fs_sbsize > SBSIZE) 549 sblock.fs_sbsize = SBSIZE; If I'm not mistaken, this will give an upper limit of effectively 8192 to fs_sbsize, which does not appear to be the case with -current: As seen in the RCS file just CVSup'ed (sbin/newfs/mkfs.c,v): 840 errx(31, "calloc failed"); 841 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 842 sblock.fs_minfree = minfree; 843 sblock.fs_maxbpg = maxbpg; There is no other reference to sbsize in the HEAD branch. Now, as soon as I patched the build I did half a month ago as follows: 386 if (fscs == NULL) 387 errx(31, "calloc failed"); 388 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 389 /* XXX HACKHACKHACK */ 390 if (sblock.fs_sbsize > SBLOCKSIZE) 391 sblock.fs_sbsize = SBLOCKSIZE; 392 sblock.fs_minfree = minfree; that is, to match how -stable does this, I can create a filesystem with fragment sizes larger than 8192 bytes (UFS2) which I can successfully mount under -current, which, without this hack, would panic my machine. `dumpfs' shows the value for sbsize no larger than 8192, while for the problem filesystems it was >8192, as large as the fragment size. Thus the question: Is this the Right Thing[tm] to do? Your fix is exactly the right thing to do. I have put it into -current. Second question: I have a drive where I first tried to create an ill- fated UFS2 filesystem, because of the above panic which I had not yet researched, so I gave up and created a UFS1 filesystem thereupon, and filled it up. It *seems* that I can mount this disk under -current and probably access the UFS1 files within, but what was really weird was the `df' output from this disk. Said disk is 100% full under -stable, but -current claims it is 0% full. Sorry I don't have the actual outputs from this command, but is it possible that the presence of the UFS2 superblock is confusing -current when there's a UFS1 superblock and filesystem present, and if -current is looking first for a UFS2 superblock and finding one, is it possible to tell `mount' that I really want a UFS1 filesystem mount, and any remnants of UFS2 should be ignored? According to ufs/ffs/fs.h, the UFS1 superblock is at 8k while UFS2 is 64k from the front, so apparently the UFS2 superblock that I initially created still remains and confuses `df' and perhaps other things that I haven't tried yet, as it didn't get wiped when I created the UFS1 filesystem. So it seems. Which makes one to wonder, if there are three superblocks at three locations present, which to believe? And how to nuke the unwanted one(s)? Insight appreciated. Thanks. barry bouwsma In general you can move UFS1 filesystems back and forth between -stable and -current. However, you must run an `fsck -f -p' using the local version (e.g., the -stable fsck on a -stable systems, and the -current fsck on a -current system) before using the UFS1 filesystem. The reason is that -stable and -current record free block information in different parts of the superblock (32-bit counters for -stable and 64-bit counters for -current) and do not maintain the alternate counter locations. The local fsck will recalculate and correct the counters that the local system uses. Unless your blocksize was bigger than 64K, you would have overwritten the UFS2 superblock with UFS1 inode blocks when you created the UFS1 filesystem. I had originally put code in to stomp out all other possible superblock locations when creating a filesystem in newfs, but got in trouble as I ended up stomping on boot block information that UFS2 filesystems place where the UFS1 superblock used to reside. So, I deleted that code. Hope this helps. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message