In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
