Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jan 2012 20:34:53 GMT
From:      Dieter <freebsd@sopwith.solgatos.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   misc/163992: dumpfs -m is broken
Message-ID:  <201201102034.q0AKYrcr059997@red.freebsd.org>
Resent-Message-ID: <201201102040.q0AKe7dA037227@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         163992
>Category:       misc
>Synopsis:       dumpfs -m is broken
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 10 20:40:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Dieter
>Release:        8.2
>Organization:
>Environment:
8.2 amd64
>Description:
The dumpfs man page promises:

"If -m is specified, a newfs(8) command is printed that can be used to
generate a new file system with equivalent settings."

However, this is a lie.  Dumpfs -m does not supply the -i option,
so the new file system reverts to the default number of inodes.

dumpfs.c says: /* -i is dumb */
The default number of inodes is rarely optimum.  In most cases I have to
greatly reduce the number of inodes.  This frees up some disk space and
reduces fsck time.  In very rare cases I have had to increase the number
of inodes.  In what universe is making more efficient use of disk space
and reducing fsck time dumb?

Might want to look at the other options as well.  For example -r looks kinda
important if one is using it.

Very disappointing.  Not what I was expecting from the best of breed.  :-(

>How-To-Repeat:
Run newfs with -i to get non-default number of inodes.
Run dumpfs -m.
Run the newfs command that dumpfs gives.
Note that you get the wrong number of inodes.
Redo several days work.  :-(

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201102034.q0AKYrcr059997>