NetBSD Problem Report #41439

From mouse@Sparkle.Rodents-Montreal.ORG  Sat May 16 07:47:28 2009
Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 8D86663C238
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 16 May 2009 07:47:28 +0000 (UTC)
Message-Id: <200905160058.UAA03750@Sparkle.Rodents-Montreal.ORG>
Date: Fri, 15 May 2009 20:45:08 -0400 (EDT)
From: der Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@gnats.NetBSD.org
Subject: [dM] undocumented newfs failure
X-Send-Pr-Version: 3.95

>Number:         41439
>Category:       bin
>Synopsis:       [dM] mildly extreme newfs arguments produce cryptic failure
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 16 07:50:00 +0000 2009
>Last-Modified:  Sat May 16 12:25:01 +0000 2009
>Originator:     der Mouse
>Release:        NetBSD 3.1
>Organization:
	Dis-
>Environment:
System: NetBSD iMac-backup.Rodents-Montreal.ORG 3.1 NetBSD 3.1 (GEN31) #0: Tue Jan 13 05:39:59 EST 2009  mouse@NetBSD-3-1.Rodents-Montreal.ORG:/home/mouse/kbuild/GEN31 i386
Architecture: i386
Machine: i386
>Description:
	For at least some combinations of arguments, newfs fails with a
	cryptic and somewhat baffling undocumented error message which
	looks like an internal can't-happen.  I wanted a filesystem
	with large blocksize and very few inodes (it's going to be used
	to store comparatively few very large files); admittedly the
	arguments are somewhat extreme, but this seems like
	a..suboptimal..failure mode.
>How-To-Repeat:
	# newfs -b 65536 -f 8192 -i 33554432 /dev/rwd2a
	CGSIZE miscalculated 65541 > 65536
	# 
	(I would have used even larger block and frag sizes, but newfs
	refuses to accept 128K blocks, saying 64K is the max.)

	In case it matters, here's "disklabel wd2" output:

	# /dev/rwd2d:
	type: ESDI
	disk: Hitachi HDT72101
	label: fictitious
	flags:
	bytes/sector: 512
	sectors/track: 63
	tracks/cylinder: 16
	sectors/cylinder: 1008
	cylinders: 1938021
	total sectors: 1953525168
	rpm: 3600
	interleave: 1
	trackskew: 0
	cylinderskew: 0
	headswitch: 0		# microseconds
	track-to-track seek: 0	# microseconds
	drivedata: 0 

	5 partitions:
	#        size    offset     fstype [fsize bsize cpg/sgs]
	 a: 976762552        63     4.2BSD      0     0     0  # (Cyl.      0*- 969010*)
	 c: 1953525105        63     unused      0     0        # (Cyl.      0*- 1938020)
	 d: 1953525168         0     unused      0     0        # (Cyl.      0 - 1938020)
	 e: 976762553 976762615     4.2BSD      0     0     0  # (Cyl. 969010*- 1938020)
>Fix:
	Unknown.  As a workaround, I tried reducing the -i figure (the
	value in how-to-repeat is 32 megs).  Repeatedly halving, I
	found that everything down to 4194304 (4M) produced the same
	error, but 2097152 (2M) worked.  I now have a filesystem, but
	one with substantially more space wasted on inodes than I'd
	like.  32M is actually conservative; the measured figure from
	another filesystem in similar live use (calculated based on
	output from df -i) is about 144M.

	At the very least, I would prefer the failure mode be less
	cryptic.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/41439: [dM] undocumented newfs failure
Date: Sat, 16 May 2009 09:13:42 +0100

 On Sat, May 16, 2009 at 07:50:00AM +0000, der Mouse wrote:
 > >Number:         41439
 > >Category:       bin
 > >Synopsis:       [dM] mildly extreme newfs arguments produce cryptic failure
 ...
 > 	For at least some combinations of arguments, newfs fails with a
 > 	cryptic and somewhat baffling undocumented error message which
 > 	looks like an internal can't-happen.

 Yes, that is a consistency check on the algorithm.
 IIRC There is another option to specify a number of inodes - which
 might work.

 Most of the testing was done for filesystems with very large numbers
 of inodes (for mfs /dev).

 	David

 -- 
 David Laight: david@l8s.co.uk

From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/41439: [dM] undocumented newfs failure
Date: Sat, 16 May 2009 07:46:10 -0400 (EDT)

 > IIRC There is another option to specify a number of inodes - which
 > might work.

 Well spotted.  Might I suggest a cross-reference to it from -i?  (This
 patch is untested.)

 --- newfs.8=    2009-05-16 07:47:09.000000000 -0400
 +++ newfs.8     2009-05-16 07:47:52.000000000 -0400
 @@ -186,6 +186,10 @@
  .It \*[Gt]= 1024 MB
  8 KB
  .El
 +.Pp
 +See
 +.Fl n
 +for another way to control this.
  .It Fl m Ar free-space
  The percentage of space reserved from normal users; the minimum free
  space threshold.

 And, yes, -n works - or, at least, it doesn't fail; it uses only one
 block of inodes per cg, but way more cgs than I'd like:

 # newfs -b 65536 -f 8192 -n 15000 /dev/rwd2e
 /dev/rwd2e: 476934.8MB (976762544 sectors) block size 65536, fragment size 8192
         using 117 cylinder groups of 4076.38MB, 65222 blks, 512 inodes.

 This means 59904 inodes where I'd rather have more like, well, 15000.
 (I really wish newfs hadn't lost -c.)  Annoying but hardly fatal.

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/41439: [dM] undocumented newfs failure
Date: Sat, 16 May 2009 13:17:51 +0100

 On Sat, May 16, 2009 at 12:00:08PM +0000, der Mouse wrote:
 > Subject: Re: bin/41439: [dM] undocumented newfs failure
 ...
 >  And, yes, -n works - or, at least, it doesn't fail; it uses only one
 >  block of inodes per cg, but way more cgs than I'd like:
 >  
 >  # newfs -b 65536 -f 8192 -n 15000 /dev/rwd2e
 >  /dev/rwd2e: 476934.8MB (976762544 sectors) block size 65536, fragment size 8192
 >          using 117 cylinder groups of 4076.38MB, 65222 blks, 512 inodes.
 >  
 >  This means 59904 inodes where I'd rather have more like, well, 15000.
 >  (I really wish newfs hadn't lost -c.)  Annoying but hardly fatal.

 The 'problem' (which ffsv2 really ought to have fixed) is that the
 allocation bitmap is constrained to fit in one fs block (64k above).
 With 64k this is 64k*8k*8 or 4G bytes per CG (less a bit for the inode map)
 so your 477G fs needs the 117 cgs.

 	David

 -- 
 David Laight: david@l8s.co.uk

NetBSD Home
NetBSD PR Database Search

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