From owner-freebsd-hackers  Sun Jan  7  7: 8:42 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 48D6A37B69B
	for <hackers@freebsd.org>; Sun,  7 Jan 2001 07:07:58 -0800 (PST)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa79033@salmon>; 7 Jan 2001 15:07:55 +0000 (GMT)
To: Jaye Mathisen <mrcpu@internetcds.com>
Cc: hackers@freebsd.org, iedowse@maths.tcd.ie,
	Kirk McKusick <mckusick@mckusick.com>
Subject: Re: fsck problem on large vinum volume 
In-Reply-To: Your message of "Sat, 06 Jan 2001 15:01:07 PST."
             <20010106150106.X32287@apocalypse.cdsnet.net> 
Date: Sun, 07 Jan 2001 15:07:54 +0000
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID:  <200101071507.aa79033@salmon.maths.tcd.ie>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20010106150106.X32287@apocalypse.cdsnet.net>, Jaye Mathisen writes:
>
>I have a 930GB vinum volume

>However, I can't fsck it, I have to always use the alternate block.

>newsfeed-inn2# fsck /dev/vinum/v-spool
>** /dev/vinum/v-spool
>BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
>/dev/vinum/v-spool: CANNOT FIGURE OUT FILE SYSTEM PARTITION

Jaye sent me a ktrace.out for the fsck that was failing. It appears
that the kernel had overshot the end of the superblock fs_csp[] array
in ffs_mountfs(), since the list of pointers there extended through
fs_maxcluster, fs_cpc, and fs_opostbl. This caused the mismatch between
the master and alternate superblocks.

The filesystem parameters were 8k/1k, and the total number of cylinder
groups was 29782. fs_cssize was 29782*sizeof(struct csum) = 477184
bytes. Hence 477184/8192 = ~59 entries were being used in fs_csp,
but fs_csp[] is only 31 entries long (15 on alpha).

A larger block size should fix Jaye's case, but I think the correct
solution is to fix the kernel so that it is not constrained by the
MAXCSBUFS limit. There are a few ways to do this:

	- Store the fs_csp information in struct ufsmount rather than
	  in the superblock.
	- Make use of the fact that the summary information is stored
	  in one contigous region, and update the 'fs_csp' macro to
	  find the right offset directly.

I'll have a look and see which way looks neatest.

Ian


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message