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

[David Wolfskill]

On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
> ...
>  > 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 
> 
> This seems to be a bug in dumpfs(8).  It simply prints
> the value of the fs_size field of the superblock, which
> is wrong.
> 
> The -s option of newfs(8) expects the available size in
> sectors (i.e. 512 bytes), but the fs_size field contains
> the size of the file system in 2KB units.  This seems to
> be the fragment size, but I'm not sure if this is just
> coincidence (the docs state that it's the size in blocks,
> but this is misleading because the blocksize is usually
> different; the default is 16K).
> 
> So, dumpfs(8) needs to be fixed to perform the proper
> calculations when printing the value for the -s option.
> Unfortunately I'm not sufficiently much of a UFS guru
> to offer a fix.  My best guess would be to multiply the
> fs_size value by the fragment size (measured in 512 byte
> units), i.e. multiply by 4 in the most common case.
> But I'm afraid the real solution is not that simple.

Empirically, I find that -- at least in the case in question -- using
the superblock's dsize, multiplied by 2, gets the correct result:

Filesystem  1024-blocks Used      Avail Capacity  Mounted on
/dev/da1s1d  1702753030 2744 1566530044     0%    /b

Extract from "ffsinfo -l 1":

===== END CYLINDER SUMMARY TOTAL =====
time              ufs_time_t       1231206211
size              int64_t          0x000000003464f664
dsize             int64_t          0x0000000032bef983
csaddr            ufs2_daddr_t     0x0000000000000bb8

A bit of messing about with dc(1):

g1-35(6.4-S)[4] dc
16
i
32BEF983
2
*
p
1702753030
g1-35(6.4-S)[5] 

Then again, it isn't especially common in my experience to want a file
system that occupies an amount of space different from the amount that
is available for the file system (e.g., the partition size).  So if that
were wanted, providing a way to have dumpfs(8) merely make no claims
whatsoever about or for the newfs(8) "-s" parameter might be adequate.

My circumvention of piping the result through sed(1) accomplishes that,
at some additional complexity and potential confusion.

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/20090106/5cdda835/attachment.pgp