xfs
[Top] [All Lists]

Re: higher agcount on LVM2 thinp volumes

To: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
Subject: Re: higher agcount on LVM2 thinp volumes
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 29 Aug 2013 22:04:14 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <321D1F95-5603-4571-A445-A267DA5F670F@xxxxxxxxxxxxxxxxx>
References: <321D1F95-5603-4571-A445-A267DA5F670F@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
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





<Prev in Thread] Current Thread [Next in Thread>