higher agcount on LVM2 thinp volumes

higher agcount on LVM2 thinp volumes

[Chris Murphy]

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?


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?


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

Re: higher agcount on LVM2 thinp volumes

[Stan Hoeppner]

On 8/29/2013 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?
> 
> 
> 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?

More information would be helpful, specifically WRT the device stack
underlying mkfs.xfs.  I.e. we need to know more about the LVM configuration.

See:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

-- 
Stan


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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 7:44 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> 
> More information would be helpful, specifically WRT the device stack
> underlying mkfs.xfs.  I.e. we need to know more about the LVM configuration.
> 
> See:
> 
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

Summary: laptop, one HDD, one 402GB partition is made into a PV, one VG is created with that PV and is the only VG on the system, one 400GB logical volume pool is created, one 100GB virtual sized logical volume is created from the thin pool.


Linux f19s.local 3.10.9-200.fc19.x86_64 #1 SMP Wed Aug 21 19:27:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

xfsprogs-3.1.10-2.fc19.x86_64
lvm2-2.02.98-12.fc19.x86_64
DMI: Apple Inc. MacBookPro4,1/Mac-F42C89C8
WDC WD5000BEVT-22ZAT0

[root@f19s ~]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.7

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CB8CACD3-0BDB-46E0-AD6A-D7F99915EA2D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 478 sectors (239.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640        49237767   23.3 GiB    AF00  Mac
   3        49237768        50507303   619.9 MiB   AB00  Recovery HD
   4        50507776        50712575   100.0 MiB   AF00  fedoraEFI
   5        50712576        67096575   7.8 GiB     8200  swap
   6        67096576       133308415   31.6 GiB    8300  fedoraroot
   7       133308416       976773134   402.2 GiB   8E00  LVM2

[root@f19s ~]# pvs
  PV         VG   Fmt  Attr PSize   PFree  
  /dev/sda7  vg1  lvm2 a--  402.19g 188.00m

[root@f19s ~]# lvdisplay
  --- Logical volume ---
  LV Name                thinp
  VG Name                vg1
  LV UUID                mKI9dj-1CsO-Ke7e-JcMM-NUDH-MpOD-yMl8Da
  LV Write Access        read/write
  LV Creation host, time f19s.local, 2013-08-29 00:14:38 -0600
  LV Pool transaction ID 1
  LV Pool metadata       thinp_tmeta
  LV Pool data           thinp_tdata
  LV Pool chunk size     4.00 MiB
  LV Zero new blocks     yes
  LV Status              available
  # open                 0
  LV Size                402.00 GiB
  Allocated pool data    0.95%
  Allocated metadata     1.12%
  Current LE             102912
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3
   
  --- Logical volume ---
  LV Path                /dev/vg1/data
  LV Name                data
  VG Name                vg1
  LV UUID                yL0g16-qjUq-20MJ-Fu3I-q5AH-H8ed-LOhNwS
  LV Write Access        read/write
  LV Creation host, time f19s.local, 2013-08-29 00:15:49 -0600
  LV Pool name           thinp
  LV Status              available
  # open                 0
  LV Size                100.00 GiB
  Mapped size            3.83%
  Current LE             25600
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4


Commands to create the thinp volume:

[root@f19s ~]# pvcreate /dev/sda7
  Physical volume "/dev/sda7" successfully created
[root@f19s ~]# vgcreate vg1 /dev/sda7
  Volume group "vg1" successfully created
[root@f19s ~]# lvcreate -L 400G --type thin-pool --thinpool thinp vg1
  device-mapper: remove ioctl on  failed: Device or resource busy
  Logical volume "thinp" created
[root@f19s ~]# lvcreate -V 100G -T vg1/thinp --name data
  Logical volume "data" created
[root@f19s ~]# mkfs.xfs /dev/vg1/data
meta-data=/dev/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


Whereas if I mkfs.xfs on /dev/sda7, or if I create a regular LV rather than a thinp volume, agcount is 4. It doesn't matter whether I create the thinp with the chunk option set to default (as above) or 1MB or 4MB.


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

Re: higher agcount on LVM2 thinp volumes

[Dave Chinner]

On Thu, Aug 29, 2013 at 08:08:25PM -0600, Chris Murphy wrote:
> 
> On Aug 29, 2013, at 7:44 PM, Stan Hoeppner
> <stan@hardwarefreak.com> wrote:
> > 
> > More information would be helpful, specifically WRT the device
> > stack underlying mkfs.xfs.  I.e. we need to know more about the
> > LVM configuration.
> > 
> > See:
> > 
> > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> 
> Summary: laptop, one HDD, one 402GB partition is made into a PV,
> one VG is created with that PV and is the only VG on the system,
> one 400GB logical volume pool is created, one 100GB virtual sized
> logical volume is created from the thin pool.
....
> meta-data=/dev/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
> 
> Whereas if I mkfs.xfs on /dev/sda7, or if I create a regular LV
> rather than a thinp volume, agcount is 4. It doesn't matter
> whether I create the thinp with the chunk option set to default
> (as above) or 1MB or 4MB.

Which means that the thinp device has some difference in what it is
telling mkfs.xfs about it's configuration that makes mkfs.xfs think
it is a RAID volume, not a single disk.

Basically, I think you'll find that the thinp device is emitting a
an optimal IO size that is not aligned to the filesystem block size,
so the AG count is being calculated as though it is a ~1TB
"multidisk" device (which gives 16 AGs) and then setting
sunit/swidth to zero because they aren't filesystem block aligned...

Check the contents of
/sys/block/<dev>/queue/{minimum,optimal}_io_size for the single
device, the standard LV and the thinp device. I think that you'll
find only the thinp device has a non-zero value. If the value from
the thinp code is 512 (i.e. single sector) then that's a bug in
the thinp device code as it should be zero...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: higher agcount on LVM2 thinp volumes

[Eric Sandeen]

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 9:04 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> What does
> 
> # blockdev --getiomin --getioopt mkfs.xfs /dev/mapper/vg1-data
> 
> say?


[root@f19s ~]# blockdev --getiomin --getioopt mkfs.xfs /dev/mapper/vg1-data
blockdev: cannot open mkfs.xfs: No such file or directory


Chris Murphy

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

Re: higher agcount on LVM2 thinp volumes

[Eric Sandeen]

On 8/29/13 10:18 PM, Chris Murphy wrote:
> 
> On Aug 29, 2013, at 9:04 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> 
>> What does
>>
>> # blockdev --getiomin --getioopt mkfs.xfs /dev/mapper/vg1-data
>>
>> say?
> 
> 
> [root@f19s ~]# blockdev --getiomin --getioopt mkfs.xfs /dev/mapper/vg1-data
> blockdev: cannot open mkfs.xfs: No such file or directory

Argh sorry, how did I type THAT?

# blockdev --getiomin --getioopt /dev/mapper/vg1-data

-Eric

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 8:58 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> Check the contents of
> /sys/block/<dev>/queue/{minimum,optimal}_io_size for the single
> device, the standard LV and the thinp device.

physical device:

[root@f19s ~]# cat /sys/block/sda/queue/minimum_io_size 
512
[root@f19s ~]# cat /sys/block/sda/queue/optimal_io_size 
0

conventional LV on that physical device:
     
[root@f19s ~]# cat /sys/block/dm-0/queue/minimum_io_size 
512
[root@f19s ~]# cat /sys/block/dm-0/queue/optimal_io_size 
0


thinp pool and LV:

lrwxrwxrwx. 1 root root       7 Aug 29 20:46 vg1-thinp -> ../dm-3

[root@f19s ~]# cat /sys/block/dm-3/queue/minimum_io_size 
512
[root@f19s ~]# cat /sys/block/dm-3/queue/optimal_io_size 
262144
[root@f19s ~]# 

lrwxrwxrwx. 1 root root       7 Aug 29 20:47 vg1-data -> ../dm-4

[root@f19s ~]# cat /sys/block/dm-4/queue/minimum_io_size 
512
[root@f19s ~]# cat /sys/block/dm-4/queue/optimal_io_size 
262144


Chris Murphy

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 9:19 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> 
> Argh sorry, how did I type THAT?
> 
> # blockdev --getiomin --getioopt /dev/mapper/vg1-data

conventional LV:
[root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
512
0

thinp LV:

[root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
512
262144

(Now I see two ways to get the same info.)


Chris Murphy

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 9:24 PM, Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Aug 29, 2013, at 9:19 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>> 
>> Argh sorry, how did I type THAT?
>> 
>> # blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 
> conventional LV:
> [root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 512
> 0
> 
> thinp LV:
> 
> [root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 512
> 262144


It's tied to the chunk size of the thinp. If I create a 4MB chunk size, ioopt goes up to match it. The default is 256KB, which reflects the values above.


[root@f19s ~]# lvcreate -L 400G --type thin-pool -c 4M --thinpool thinp vg1
  device-mapper: remove ioctl on  failed: Device or resource busy
  Logical volume "thinp" created
[root@f19s ~]# lvcreate -V 100G -T vg1/thinp --name data
  Logical volume "data" created
[root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
512
4194304


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

Re: higher agcount on LVM2 thinp volumes

[Eric Sandeen]

On 8/29/13 10:24 PM, Chris Murphy wrote:
> 
> On Aug 29, 2013, at 9:19 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>>
>> Argh sorry, how did I type THAT?
>>
>> # blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 
> conventional LV:
> [root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 512
> 0
> 
> thinp LV:
> 
> [root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
> 512
> 262144
> 
> (Now I see two ways to get the same info.)

:)

ok so it says the stripe unit (minimum IO size) is 512...

Around line 2240, it does:

        if (dsunit && !(BBTOB(dsunit) % blocksize) &&
            dswidth && !(BBTOB(dswidth) % blocksize)) {
...
        } else {
                if (nodsflag)
                        dsunit = dswidth = 0;

essentially saying: If we autodetected a stripe unit or stripe width
which is not a multiple of the block size, silently set it to 0.
So we do that.

However, _just_ before this, we did:

                calc_default_ag_geometry(blocklog, dblocks,
                                dsunit | dswidth, &agsize, &agcount);

when dsunit & dswidth were still set (to invalid values).

So we calculated it w/ stripe geom set, got more AGs, then zeroed
out the stripe geom.

I'm ... not sure how many bugs are here.  ;)  We shouldn't calculate
AG geometry until we've validated sunit/swidth, I think.  But I'm not
convinced that dm-thinp's exported values make a lot of sense either.

-Eric


> 
> Chris Murphy
> 

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

Re: higher agcount on LVM2 thinp volumes

[Dave Chinner]

On Thu, Aug 29, 2013 at 09:21:15PM -0600, Chris Murphy wrote:
> 
> On Aug 29, 2013, at 8:58 PM, Dave Chinner <david@fromorbit.com> wrote:
> > 
> > Check the contents of
> > /sys/block/<dev>/queue/{minimum,optimal}_io_size for the single
> > device, the standard LV and the thinp device.
> 
> physical device:
> 
> [root@f19s ~]# cat /sys/block/sda/queue/minimum_io_size 
> 512
> [root@f19s ~]# cat /sys/block/sda/queue/optimal_io_size 
> 0
> 
> conventional LV on that physical device:
>      
> [root@f19s ~]# cat /sys/block/dm-0/queue/minimum_io_size 
> 512
> [root@f19s ~]# cat /sys/block/dm-0/queue/optimal_io_size 
> 0
> 
> 
> thinp pool and LV:
> 
> lrwxrwxrwx. 1 root root       7 Aug 29 20:46 vg1-thinp -> ../dm-3
> 
> [root@f19s ~]# cat /sys/block/dm-3/queue/minimum_io_size 
> 512
> [root@f19s ~]# cat /sys/block/dm-3/queue/optimal_io_size 
> 262144
> [root@f19s ~]# 
> 
> lrwxrwxrwx. 1 root root       7 Aug 29 20:47 vg1-data -> ../dm-4
> 
> [root@f19s ~]# cat /sys/block/dm-4/queue/minimum_io_size 
> 512
> [root@f19s ~]# cat /sys/block/dm-4/queue/optimal_io_size 
> 262144

Yup, there's the problem - minimum_io_size is 512 bytes, which is
too small for a stripe unit to be set to. Hence sunit/swidth get set
to zero.

The problem here is that minimum_io_size is not the minimum IO size
that can be done, but the minimum IO size that is *efficient*. For
example, my workstation has a MD RAID0 device with a 512k chunk size
and two drives:

$ cat /sys/block/md0/queue/minimum_io_size 
524288
$ cat /sys/block/md0/queue/optimal_io_size 
1048576

Here we see the minimum *efficient* IO size is the stripe chunk size
(i.e. what gets written to a single disk) and the optimal is an IO
that hits all disks at once.

So, what dm-thinp is trying to tell us is that the minimum
*physical* IO size is 512 bytes (i.e. /sys/.../physical_block_size)
but the efficient IO size is 256k. So dm-thinp is exposing the
information incorrectly. What it shoul dbe doing is setting both the
minimum_io_size and the optimal_io_size to the same value of 256k...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 29, 2013, at 9:38 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
> So, what dm-thinp is trying to tell us is that the minimum
> *physical* IO size is 512 bytes (i.e. /sys/.../physical_block_size)
> but the efficient IO size is 256k. So dm-thinp is exposing the
> information incorrectly. What it shoul dbe doing is setting both the
> minimum_io_size and the optimal_io_size to the same value of 256k…

Should I file a bug? Against lvm2?



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

Re: higher agcount on LVM2 thinp volumes

[Eric Sandeen]

On Aug 30, 2013, at 12:55 PM, Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Aug 29, 2013, at 9:38 PM, Dave Chinner <david@fromorbit.com> wrote:
>> 
>> So, what dm-thinp is trying to tell us is that the minimum
>> *physical* IO size is 512 bytes (i.e. /sys/.../physical_block_size)
>> but the efficient IO size is 256k. So dm-thinp is exposing the
>> information incorrectly. What it shoul dbe doing is setting both the
>> minimum_io_size and the optimal_io_size to the same value of 256k…
> 
> Should I file a bug? Against lvm2?
> 
> 
I think so.  They may already be aware of it but better to not lose it...

Eric

> 
> Chris Murphy
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

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

Re: higher agcount on LVM2 thinp volumes

[Chris Murphy]

On Aug 30, 2013, at 7:22 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> I think so.  They may already be aware of it but better to not lose it…


Done.

https://bugzilla.redhat.com/show_bug.cgi?id=1003227

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