kern/50246: lfs volumes created with wrong ifpb value

[dholland%netbsd.org@localhost]

>Number:         50246
>Category:       kern
>Synopsis:       lfs volumes created with wrong ifpb value
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 14 17:40:00 +0000 2015
>Originator:     David A. Holland
>Release:        NetBSD 7.99.21 (20150914)
>Organization:
>Environment:
System: NetBSD macaran 7.99.20 NetBSD 7.99.20 (MACARAN) #30: Mon Jul 27 20:25:15 EDT 2015  dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

If you newfs a 32-bit lfs volume with a non-default block size, it
recalculates a number of superblock fields that depend on the block
size. The recalculation of 'ifpb' (ifile entries per block) uses
sizeof(IFILE); unfortunately, since the introduction of separate
IFILE32/IFILE64 structures on 20150812, IFILE is a union and its size
is the size of the (larger) IFILE64 structure. Therefore, the ifpb
value recorded in the superblock is smaller than it should be.

This *should* be harmless (at a cost of some wasted space) as all code
should be using the superblock ifpb value and not recomputing it on
the fly; but this is not guaranteed and there's a certain risk of
stepping on otherwise-invisible bugs.

>How-To-Repeat:

Code inspection.

>Fix:

The fix is trivial (and pending once I chase down some test failures
that probably aren't related); the question is what the consequences
are. Once the fix is in place, if you have such a volume and can
easily re-newfs it, it's probably a good idea to do so as a safety
precaution. 

(The space consumption isn't that big a deal; while the ifile entry in
lfs64 is substantially larger, 32 bytes vs. 20, the space wasted works
out to something like 0.1% of the volume size.)