Re: Possible issue with fsck_ffs ?

[christos%astron.com@localhost (Christos Zoulas)]

In article <Pine.NEB.4.64.1402070830020.23078%screamer.whooppee.com@localhost>,
Paul Goyette  <paul%whooppee.com@localhost> wrote:
>I'm sure we have some experts who could figure this out a lot more 
>quickly than me fumbling through the sources....  :)
>
>At my $DAYJOB we have seen instances where newfs(8) can generate a 
>filesystem with "fragments per cylinder-group" can exceed 0x10000.  When 
>newfs(8) stores the value in the file-system's superblock, it works 
>correctly since fs_fpg is a 32-bit integer.  However, newfs(8) also 
>stores the value in the partition table's p_cpg member, which is only 
>16-bits.  Values above 0x10000 will, obviously, get truncated.
>
>fsck_ffs(8) works just fine as long as we are able to read the primary 
>superblock.  But if we're unable to access the primary SB, we need to 
>use the p_cpg value to find the alternate superblocks, and because of 
>the truncation noted above the search for alternates will fail.
>
>Is there someone who can check/inspect NetBSD to see if we suffer from 
>this possible truncation?
>
>(Please cc me on responses, as I'm not subscribed to tech-userlevel)

I don't see any instances of the word disklabel or p_cpg exists in
fsck_ffs, or fsck. I killed the disklabel code a while ago for the
new disk geometry stuff. Having said that, this does not mean that
we fare any better in guessing the location of the first alternate
superblock. OTOH, you could always use newfs -N / fsck -b  to find
it, or other intelligent experimentation.

christos