Re: Possible issue with fsck_ffs ?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Feb 07, 2014 at 08:39:39AM -0800, Paul Goyette 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?

I can (many people probably can) but I'm not sure when I'll have time
to. I'm replying mainly for the following:

 > (Please cc me on responses, as I'm not subscribed to tech-userlevel)

Also, I'm moving this to tech-kern where filesystem folks will see it,
because it's a filesystem issue (even though fsck is a user binary).

I have set Mail-Followup-To:; if replying please check that it worked.

-- 
David A. Holland
dholland%netbsd.org@localhost