Bug 1003227 - sysfs reports incorrect minimum_io_size for thinp volumes
sysfs reports incorrect minimum_io_size for thinp volumes
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mike Snitzer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-31 23:38 EDT by Chris Murphy
Modified: 2015-02-24 10:49 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1121779 (view as bug list)
Environment:
Last Closed: 2015-02-24 10:49:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Murphy 2013-08-31 23:38:29 EDT
Description of problem: When formatting a thinp LV as XFS, agcount is unexpectedly high. Apparently mkfs.xfs initially thinks stripe geometry applies and therefore creates more ag's than if a conventional LV of the same size is formatted; or if a physical disk partition of the same size is formatted.


Version-Release number of selected component (if applicable):
lvm2-2.02.98-12.fc19.x86_64

kernel 3.10.9-200.fc19.x86_64
xfsprogs-3.1.10-2.fc19.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Create a 100GB thinp LV; a 100GB conventional LV; and 100GB disk partition.
2. Format each of them with mkfs.xfs without any options.


Actual results:
AG count = 16 for thinp LV; 4 for the other two.

Expected results:
thinp LV should also be 4.

Additional info:

Thread from XFS list elicited responses from XFS devs:

http://oss.sgi.com/pipermail/xfs/2013-August/029626.html
http://oss.sgi.com/pipermail/xfs/2013-August/029619.html
http://oss.sgi.com/pipermail/xfs/2013-August/029625.html
Comment 1 Eric Sandeen 2013-09-01 00:17:51 EDT
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
Comment 2 Chris Murphy 2014-02-27 18:21:57 EST
Still a bug, bumping to Fedora 20.

## virtual size LV, 2TB
# mkfs.xfs /dev/VG/vLV
meta-data=/dev/VG/vLV             isize=256    agcount=32, agsize=16777216 blks

## conventional LV, 2TB
# mkfs.xfs /dev/VG/cLV
meta-data=/dev/VG/cLV            isize=256    agcount=4, agsize=134217728 blks


I'd think this would make any fragmentation problems worse.
Comment 4 Mike Snitzer 2014-07-18 17:33:23 EDT
(In reply to Chris Murphy from comment #0)

> Additional info:
> 
> Thread from XFS list elicited responses from XFS devs:
> 
> http://oss.sgi.com/pipermail/xfs/2013-August/029626.html

Hmm, ok so dchinner said:

"What it should be doing is setting both the minimum_io_size and the optimal_io_size to the same value of 256k..."

I guess I can buy that...

(btw.. would've been _wonderful_ if I was cc'd on the original xfs mailing list thread.  I clearly missed this BZ in the flood of BZ updates I tend to get)
Comment 5 Mike Snitzer 2014-07-18 18:23:03 EDT
I've staged a fix for 3.17 in linux-dm.git's 'for-next' branch here:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=a99c223c2a88aeb404afaa1bfce91eb0dd36b80b
Comment 6 Josh Boyer 2014-11-05 19:24:30 EST
This went into 3.17 as commit fdfb4c8c1a9fc8dd8cf8eeb4e3ed83573b375285.  F20 is rebased at this point.

Note You need to log in before you can comment on or make changes to this bug.