Date: Mon, 26 Apr 2010 15:58:31 +0200 From: "Lister" <lister@kawashti.org> To: "Andriy Gapon" <avg@icyb.net.ua> Cc: GEOM <freebsd-geom@freebsd.org> Subject: Re: OCE and GPT. No Dice! Message-ID: <8918FD47C14E4E15B944767526733C02@neo> References: <2ADD2F3170654D21818307E326F42E83@neo> <4BD58D69.1030308@icyb.net.ua> <31480C3D06384DB581253007A52C6F61@neo> <4BD5966C.1030903@icyb.net.ua> <4BD59A21.9070509@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
$ dumpfs /dev/da0p2 magic 19540119 (UFS2) time Sun Apr 25 20:40:18 2010 superblock location 65536 id [ 4bd08383 b5a1e1a4 ] ncg 205 size 50384895 blocks 50359677 bsize 65536 shift 16 mask 0xffff0000 fsize 65536 shift 16 mask 0xffff0000 frag 1 shift 0 fsbtodb 7 minfree 8% optim time symlinklen 120 maxbsize 65536 maxbpg 8192 maxcontig 2 contigsumsize 2 nbfree 49949427 ndir 5 nifree 6350052 nffree 0 bpg 245897 fpg 245897 ipg 30976 unrefs 0 nindir 8192 inopb 256 maxfilesize 36033195603132415 sbsize 8192 cgsize 65536 csaddr 125 cssize 65536 sblkno 2 cblkno 3 iblkno 4 dblkno 125 cgrotor 57 fmod 0 ronly 0 clean 1 avgfpdir 64 avgfilesize 16384 flags soft-updates fsmnt /SH/huge volname swuid 0 I'd also like to suggest growfs be in a bug state for the same reason as dumpfs. It reports its error in blocks while it takes input in sectors. ----- Hatem Kawashti ----- Original Message ----- From: "Andriy Gapon" <avg@icyb.net.ua> To: "Lister" <lister@kawashti.org> Sent: Monday, April 26, 2010 15:50 Subject: !Probable-UBE! Re: OCE and GPT. No Dice! > on 26/04/2010 16:34 Andriy Gapon said the following: >> on 26/04/2010 16:31 Lister said the following: >>> I didn't think 50384895 was in blocks because growfs itself takes -s >>> <sectors> for input and it's man page has nothing about errors in >>> blocks, or at all! >>> Again, according to dumpfs manpage, and I quote "If -m is specified, a >>> newfs(8) command is printed that can be used to generate a new file >>> system with equivalent settings." newfs takes -s <sectors> not blocks. >>> Given that, dumpfs has a bug, at least with -m option. >> >> Yep, I agree, it's a mess. > > In fact, it's quite strange. > Can you provide output of dumpfs without -m option, only the header (before first > blank line)? > > > -- > Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8918FD47C14E4E15B944767526733C02>