From owner-freebsd-current Fri Oct 18 14: 7: 0 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 7A8EA37B401 for ; Fri, 18 Oct 2002 14:06:58 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient80-218-16-13.hispeed.ch [80.218.16.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2D8843E88 for ; Fri, 18 Oct 2002 14:06:56 -0700 (PDT) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from MAIL.NetScum.DynDNS.dK (ipv6.NetScum.dyndns.dk [2002:50da:100d:0:250:daff:fe21:edca]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id g9IL6rH21576 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 18 Oct 2002 23:06:54 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by MAIL.NetScum.DynDNS.dK (8.11.6/SMI-4.1-R00T0WNED) id g9IL6rN21575; Fri, 18 Oct 2002 23:06:53 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Fri, 18 Oct 2002 23:06:53 +0200 (CEST) Message-Id: <200210182106.g9IL6rN21575@MAIL.NetScum.DynDNS.dK> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: CABAL MODEM (all hail CABAL) To: freebsd-current@freebsd.org Subject: Stupid UFS2 questions... X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No 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 [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