newfs(8) parameters from "dumpfs -m" have bad -s value?

[David Wolfskill]

I have a requirement to be able to re-create a largish file system on
occasion.  The file system was created with some non-default newfs(8)
parameters.

Once I found about it, it seemed that the output of "dumpfs -m"
would be ideal to use in the script that performs the analysis &
(if appropriate) re-creation.

But I found that that output (in this case, at least) includes a rather
bogus "-s" parameter.  A circumvention is to interpose a sed(1)
invocation to elide the parameter, but that seems a tad ... ugly (though
admittedly effective).

I'm running 7.1-RC1 on the systems in question.

Here's the supporting evidence:

We start with one of the file systems in question as it is supposed to be:

pool10(7.1-RC1)[32] df -ki /dev/da1s1d
Filesystem  1024-blocks Used      Avail Capacity iused     ifree %iused  Mounted on
/dev/da1s1d  1702753030    4 1566532784     0%       2 220046332    0%   /b
pool10(7.1-RC1)[33] 

Here's what dumpfs(8) says:

pool10(7.1-RC1)[36] dumpfs -m /dev/da1s1d
# newfs command for /dev/da1s1d (/dev/da1s1d)
newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 8 -o time -s 879031908 /dev/da1s1d 
pool10(7.1-RC1)[37] 

I then unmount the file system & re-create it naively:

pool10(7.1-RC1)[37] umount /dev/da1s1d
pool10(7.1-RC1)[38] dumpfs -m /dev/da1s1d | sh
/dev/da1s1d: 429214.8MB (879031908 sectors) block size 16384, fragment size 2048
        using 2336 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
...
 876523968, 876900320, 877276672, 877653024, 878029376, 878405728, 878782080
pool10(7.1-RC1)[39] df -ki /dev/da1s1d
Filesystem         1024-blocks      Used     Avail Capacity  iused    ifree %iused  Mounted on
/dev/da1s1d          425686716         4 391631776     0%        2 55017468    0%   
pool10(7.1-RC1)[40] 

The file system had been 1702753030 KB; it is now 425686716 KB -- 25% of its
intended size.

By eliding the -s parameter, we get:

pool10(7.1-RC1)[40] dumpfs -m /b | sed -Ee 's/ -s [0-9]+ / /' | sh
/dev/da1s1d: 1716859.2MB (3516127632 sectors) block size 16384, fragment size 2048
        using 9343 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
...
 3513622432, 3513998784, 3514375136, 3514751488, 3515127840, 3515504192,
 3515880544
pool10(7.1-RC1)[41] df -ki /dev/da1s1d
Filesystem         1024-blocks      Used     Avail Capacity  iused    ifree %iused  Mounted on
/dev/da1s1d         1702753030         4 1566532784     0%        2 220046332    0%   
pool10(7.1-RC1)[42] 

[Sorry about the long lines....]

Is dumpfs(8) actually behaving as expected (or correctly) in this case?

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090102/e0bb45dc/attachment.pgp