public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Chris Murphy <lists@colorremedies.com>
Cc: xfs@oss.sgi.com
Subject: Re: higher agcount on LVM2 thinp volumes
Date: Thu, 29 Aug 2013 22:04:14 -0500	[thread overview]
Message-ID: <52200BAE.1060501@sandeen.net> (raw)
In-Reply-To: <321D1F95-5603-4571-A445-A267DA5F670F@colorremedies.com>

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-08-30  3:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29  6:09 higher agcount on LVM2 thinp volumes Chris Murphy
2013-08-30  1:44 ` Stan Hoeppner
2013-08-30  2:08   ` Chris Murphy
2013-08-30  2:58     ` Dave Chinner
2013-08-30  3:21       ` Chris Murphy
2013-08-30  3:38         ` Dave Chinner
2013-08-30 17:55           ` Chris Murphy
2013-08-31  1:22             ` Eric Sandeen
2013-09-01  3:39               ` Chris Murphy
2013-08-30  3:04 ` Eric Sandeen [this message]
2013-08-30  3:18   ` Chris Murphy
2013-08-30  3:19     ` Eric Sandeen
2013-08-30  3:24       ` Chris Murphy
2013-08-30  3:29         ` Chris Murphy
2013-08-30  3:35         ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52200BAE.1060501@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=lists@colorremedies.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox