Re: newfs(8) parameters from "dumpfs -m" have bad -s value?
- From: David Wolfskill <david@xxxxxxxxxxxxxx>
- Date: Mon, 5 Jan 2009 21:49:07 -0800
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@xxxxxxxxxxxxxx
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Attachment:
pgpR4I8wzRNgD.pgp
Description: PGP signature
- References:
- newfs(8) parameters from "dumpfs -m" have bad -s value?
- From: David Wolfskill
- Re: newfs(8) parameters from "dumpfs -m" have bad -s value?
- From: Oliver Fromme
- newfs(8) parameters from "dumpfs -m" have bad -s value?
- Prev by Date: 7.1 Live Filesystem CD
- Next by Date: Re: HEADS UP: snd_hda MFC plan
- Previous by thread: Re: newfs(8) parameters from "dumpfs -m" have bad -s value?
- Next by thread: FreeBSD 7.1 svn186551
- Index(es):
Relevant Pages
|
