Re: mkfs.xfs doesn't detect size of storage correctly

[Matthias Schniedermeyer <ms@citd.de>]

On 29.01.2008 10:32, Matthias Schniedermeyer wrote:
> Hi
> 
> 
> Yesterday i bought a 750GB HDD.
> I encrypt nearly everything with loop-aes, so i also did it with this 
> HDD.
> 
> I create a "fake" partition table and:
> losetup -e aes256 -p 0 -o 4096 /dev/loop6 /dev/sdb < key
> 
> This creates a loop with everything except the first 4KB, i.e. it leaves 
> out the MBR and another 3,5KB.
> 
> /proc/partions shows the correct(tm) size informations for the HDD and 
> the loop:
> - snip -
>    7     6  732574580 loop6
>    8    16  732574584 sdb
>    8    17  732572001 sdb1
> - snip -
> 
> But when i mkfs.xfs the loop
> #> mkfs.xfs /dev/loop6
> meta-data=/dev/loop6             isize=256    agcount=3, agsize=45785911 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=137357733, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=32768, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0

I just found a workaround. :-)
As can be seen above the agcount is 3.

For a reason that lays years in the past, when there were issues with 
the agcount (actually agsize), that to the best of my knowledge are 
fixed years ago (but still cause a weird feeling whenever i see that 
word) i just tried '-d agcount=4'

#> mkfs.xfs -l size=1024b -d agcount=4 /dev/loop6 -f
meta-data=/dev/loop6             isize=256    agcount=4, agsize=45785912 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=183143645, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

As can be seen the "blocks"-number is much higher.

#> df -k /mnt
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop6           732570484      4256 732566228   1% /mnt

matches(tm) with the loop-size.


So i'm "burned" by agcount/agsize AGAIN, seems my weird feeling about 
those two words are still with reason. ;-)






Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.