[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Possible issue with fsck_ffs ?
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
Main Index |
Thread Index |