NetBSD Problem Report #50246

From  Mon Sep 14 17:36:48 2015
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer "Postmaster" (verified OK))
	by (Postfix) with ESMTPS id 4637BA654F
	for <>; Mon, 14 Sep 2015 17:36:48 +0000 (UTC)
Message-Id: <>
Date: Mon, 14 Sep 2015 17:36:48 +0000 (UTC)
Subject: lfs volumes created with wrong ifpb value
X-Send-Pr-Version: 3.95

>Number:         50246
>Category:       kern
>Synopsis:       lfs volumes created with wrong ifpb value
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    dholland
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 14 17:40:00 +0000 2015
>Last-Modified:  Mon Sep 21 02:13:51 +0000 2015
>Originator:     David A. Holland
>Release:        NetBSD 7.99.21 (20150914)
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

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.


Code inspection.


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

(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.)



Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-When: Mon, 14 Sep 2015 17:52:30 +0000

From: "David A. Holland" <>
Subject: PR/50246 CVS commit: src
Date: Mon, 21 Sep 2015 01:24:59 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Mon Sep 21 01:24:58 UTC 2015

 Modified Files:
 	src/sbin/dump_lfs: lfs_inode.c
 	src/sbin/newfs_lfs: make_lfs.c
 	src/sys/ufs/lfs: lfs_accessors.h

 Log Message:
 Fix some assorted 32-bit assumptions not yet otherwise handled.

 Also apply patch to fix the overt problem in PR 50246: newfs was
 calculating ifpb wrong for volumes with non-default block sizes.

 To generate a diff of this commit:
 cvs rdiff -u -r1.26 -r1.27 src/sbin/dump_lfs/lfs_inode.c
 cvs rdiff -u -r1.56 -r1.57 src/sbin/newfs_lfs/make_lfs.c
 cvs rdiff -u -r1.32 -r1.33 src/sys/ufs/lfs/lfs_accessors.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->analyzed
State-Changed-When: Mon, 21 Sep 2015 02:13:51 +0000
mistake is fixed, still contemplating steps to take regarding extant
volumes that may have been created this way.


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.