Re: newfs(8) parameters from dumpfs -m have bad -s value?
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 /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. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: newfs(8) parameters from dumpfs -m have bad -s value?
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 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 This *is* the fragment size. UFS/FFS uses the plain term block to mean the fragment size. All blocks are indexed with this number, unlike block size which is almost always 8 fragments (blocks). Confusing. 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. The sector size and filesystem size parameters in newfs are remnants. 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, and then output -S 512. Better yet would be to add a parameter (-z perhaps) to newfs(8) to accept number of bytes instead of multiples of sectorsize. I would be willing to write up patches for dumpfs and newfs to both add the raw byte size and the 512-byte sector size handling to correct said mistake, unless someone else would rather. -- Rick C. Petty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: newfs(8) parameters from dumpfs -m have bad -s value?
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 0x3464f664 dsize int64_t 0x32bef983 csaddrufs2_daddr_t 0x0bb8 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 da...@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. pgpMjhoIuTjTg.pgp Description: PGP signature
Re: newfs(8) parameters from dumpfs -m have bad -s value?
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 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 This *is* the fragment size. UFS/FFS uses the plain term block to mean the fragment size. All blocks are indexed with this number, unlike block size which is almost always 8 fragments (blocks). Confusing. 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. The sector size and filesystem size parameters in newfs are remnants. 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, and then output -S 512. don't assume 512, in the iscsi world I have seen all kinds of sector sizes, making it a PITA to get things right. Better yet would be to add a parameter (-z perhaps) to newfs(8) to accept number of bytes instead of multiples of sectorsize. I would be willing to write up patches for dumpfs and newfs to both add the raw byte size and the 512-byte sector size handling to correct said mistake, unless someone else would rather. -- Rick C. Petty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: newfs(8) parameters from dumpfs -m have bad -s value?
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, and then output -S 512. don't assume 512, in the iscsi world I have seen all kinds of sector sizes, making it a PITA to get things right. It was a suggestion, one assumed by FreeBSD in many places. In this case, it makes no difference since the number of bytes is computed by newfs and then divided by the actual sector size when calling bwrite(3). I still would prefer: Better yet would be to add a parameter (-z perhaps) to newfs(8) to accept number of bytes instead of multiples of sectorsize. -- Rick C. Petty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
