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 dholl...@netbsd.org