David Wolfskill wrote:
pool10(7.1-RC1)[32] df -ki /dev/da1s1d
Filesystem 1024-blocks Used Avail Capacity iused ifree %iused
Mounted on
/dev/da1s1d 17027530304 1566532784 0% 2 2200463320% /b
Here's what dumpfs(8) says:
pool10(7.1-RC1)[36] dumpfs -m
On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
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
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
On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
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
On Tue, Jan 06, 2009 at 08:51:18AM +0200, Danny Braniss wrote:
Everything is converted to number of media sectors (sector size as
specified by the device). So one could assume for dumpfs to always use
512, since it's rarely different, and multiply fs_size by fs_fsize and
divide by 512,
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)
