Date: Fri, 18 Oct 2002 16:30:54 -0700 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: BOUWSMA Beery <freebsd-misuser@netscum.dyndns.dk> Cc: Robert Watson <rwatson@FreeBSD.org>, freebsd-current@FreeBSD.org Subject: Re: Stupid UFS2 questions... Message-ID: <200210182330.g9INUs59098884@beastie.mckusick.com> In-Reply-To: Your message of "Fri, 18 Oct 2002 17:13:08 EDT." <Pine.NEB.3.96L.1021018171246.74278W-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Fri, 18 Oct 2002 23:06:53 +0200 (CEST)
From: BOUWSMA Beery <freebsd-misuser@netscum.dyndns.dk>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210182330.g9INUs59098884>