Date: Fri, 2 Jan 2009 07:34:55 -0800 From: David Wolfskill <david@catwhisker.org> To: stable@freebsd.org Subject: newfs(8) parameters from "dumpfs -m" have bad -s value? Message-ID: <20090102153455.GR4100@albert.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--mV+g5V4x6ti+sJEm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 Mo=
unted on
/dev/da1s1d 1702753030 4 1566532784 0% 2 220046332 0% /b
pool10(7.1-RC1)[33]=20
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=20
pool10(7.1-RC1)[37]=20
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,
=2E..
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% =20
pool10(7.1-RC1)[40]=20
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 si=
ze 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,
=2E..
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 2200463=
32 0% =20
pool10(7.1-RC1)[42]=20
[Sorry about the long lines....]
Is dumpfs(8) actually behaving as expected (or correctly) in this case?
Peace,
david
--=20
David H. Wolfskill david@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.
--mV+g5V4x6ti+sJEm
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkleNB4ACgkQmprOCmdXAD1fAwCfcWjJaUJYn6I8Ski9gUffbX7n
OosAnRgOiAbZ5j+MNqo5gJ7RyAsmE1yC
=gkZ8
-----END PGP SIGNATURE-----
--mV+g5V4x6ti+sJEm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090102153455.GR4100>