Bug 1003227

Summary:	sysfs reports incorrect minimum_io_size for thinp volumes
Product:	[Fedora] Fedora	Reporter:	Chris Murphy <bugzilla>
Component:	kernel	Assignee:	Mike Snitzer <msnitzer>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	agk, bmarzins, bmr, dwysocha, esandeen, gansalmon, heinzm, itamar, jonathan, kernel-maint, lvm-team, madhu.chinakonda, mchehab, msnitzer, prajnoha, prockai, thornber, zkabelac
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1121779 (view as bug list)		Environment:
Last Closed:	2015-02-24 15:49:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Chris Murphy 2013-09-01 03:38:29 UTC

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 04:17:51 UTC

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 23:21:57 UTC

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 21:33:23 UTC

(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 22:23:03 UTC

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-06 00:24:30 UTC

This went into 3.17 as commit fdfb4c8c1a9fc8dd8cf8eeb4e3ed83573b375285.  F20 is rebased at this point.