Bug 1003227 - sysfs reports incorrect minimum_io_size for thinp volumes
sysfs reports incorrect minimum_io_size for thinp volumes
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mike Snitzer
Fedora Extras Quality Assurance
Depends On:
  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)
Last Closed: 2015-02-24 10:49:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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):

kernel 3.10.9-200.fc19.x86_64

How reproducible:

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:

Comment 1 Eric Sandeen 2013-09-01 00:17:51 EDT
conventional LV:
[root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data

thinp LV:
[root@f19s ~]# blockdev --getiomin --getioopt /dev/mapper/vg1-data
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:
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.