Re: higher agcount on LVM2 thinp volumes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/29/13 1:09 AM, Chris Murphy wrote:
> 
> Is it expected when formatting, using defaults, that a thinp volume
> compared to either a conventional LV or partition of the same size,
> should have a higher agcount?

woohoo, thinp testing! :)

> 
> HDD, GPT partitioned, 100GB partition size:
> 
> [root@f19s ~]# mkfs.xfs /dev/sda7
> meta-data=/dev/sda7              isize=256    agcount=4, agsize=6553600 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=26214400, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=12800, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> 
> A 400GB partition, made into PV, PV added to VG, and all extents put into a thinpool volume, a 100GB virtual sized LV:
> 
> [root@f19s ~]# mkfs.xfs /dev/mapper/vg1-data
> meta-data=/dev/mapper/vg1-data   isize=256    agcount=16, agsize=1638400 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=26214400, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=12800, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> 
> 
> I get agcount=4 on a conventional LV as well. Why agcount=16 on thinp?

Hm.

calc_default_ag_geometry() in mkfs does this stuff.  There is a "multidisk" mode
which creates more AGs, but you don't have any stripe geometry set, which is what
is supposed to trigger it.

What does

# blockdev --getiomin --getioopt mkfs.xfs /dev/mapper/vg1-data

say?  I'm guessing we picked multidisk mode due to what looks like stripe
geometry, but then maybe it was out of bounds, and we turned it back off.

Or something... that does seem likely though, because on the same sized
fs created on a file:

w/o stripe geometry we get 4 ags:

$ mkfs.xfs -dfile,name=testfile,size=107374182400
meta-data=testfile               isize=256    agcount=4, agsize=6553600 blks
...

w/ stripe geometry we get 16 ags:

$ mkfs.xfs -dfile,name=testfile,size=107374182400,su=64k,sw=4
meta-data=testfile               isize=256    agcount=16, agsize=1638384 blks
...

so at the time we calculated AGs, we thought we had stripe geometry, and then
eventually discarded it.

-Eric





_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux