Date: Fri, 18 Oct 2002 23:06:53 +0200 (CEST) From: BOUWSMA Beery <freebsd-misuser@ipv6.netscum.dyndns.dk> To: freebsd-current@freebsd.org Subject: Stupid UFS2 questions... Message-ID: <200210182106.g9IL6rN21575@MAIL.NetScum.DynDNS.dK>
next in thread | raw e-mail | index | archive | help
[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?
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
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?200210182106.g9IL6rN21575>