Bug 147679
Summary: | kernel dm striped: device has a worse reading speed using a larger disk stripe | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Robert Scheck <redhat-bugzilla> | ||||
Component: | kernel | Assignee: | Milan Broz <mbroz> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Cluster QE <mspqa-list> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.0 | CC: | agk, brilong, coughlan, dwysocha, herrold, kbsingh, k.georgiou, mbroz, mgahagan, milan.kerslager, mishu, notting, pvrabec, robert.scheck, swhiteho, zkabelac | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | kernel-2.6.32-14.el6 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-11-15 14:21:21 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 245150 | ||||||
Bug Blocks: | 430698 | ||||||
Attachments: |
|
Description
Robert Scheck
2005-02-10 15:31:09 UTC
Reassigned from Fedora Core devel to Red Hat Enterprise Linux 4. Ping? This problem makes LVM2 mostly unusable for us and our customers at productive use... We also get similar worse results, if we use LVM2 for a larger disk stripe out of SCSI disks - ~ 480 MB/s writing and only ~ 120 MB/s reading, that means, we can read four times slower than write...and the disk system is able to handle normally ~ 480 MB/s reading and writing! Ah and for this results, SELinux was also disabled. Enabled SELinux doesn't improve the results in any way... Come on - please :) Folks, what's up?! This is really a serious problem of RHEL4!! We've got currently a further setup with a HP MSA30 (14 SCSI disks, 2 channels): A LVM2 stripe delivers only ~ 175 MB/s reading, while a software raid (striped) provides ~ 350-400 MB/s at reading! Writing speed at LVM2 is absolutely okay, but reading is worse :-( Could we please get a working update soon? Milan, are you planning to work on this issue or will it be as usual like in the last two years: Nobody from Red Hat, Inc. cares about this report. Device-mapper doesn't calculate readahead for the stripe target, so the value is not optimal and it leads to read performance degradation. As a workaround you can set readahead for device mapper device by running blockdev --setra <value in 512b sectors> /dev/mapper/<stripped device> For best performace set "N * drive_readahead" (use --getra to check for current value) but this will be too memory consuming, so you can try to set readahead to 2 * stripe_size. Is it enough to solve problem with your configuration ? I am not able simulate such big differences in read/write performance - there can be another problem. Anyway, stripe target should be modified to calculate this automatically. Changing component to kernel, not related to LVM2 package. Created attachment 147784 [details]
Proposed patch
Add readahead calculation to dm raid0 target.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Comment on attachment 147784 [details]
Proposed patch
Patch is not correct, cannot do this in stripe constructor.
There are at least two problems - small readahead, seems that we can do this from userspace, moved to bug 245150 - device mapper core splits big io requests to max. page size (and this decreases performance). Experimental patches for merging requests exists, but not yet upstream and need kABI changes (RHEL4 backporting can be very problematic). (See bug 232843 too). Jens proposes wrapping the parameters being passed into a struct - I'm happy with that Do we accept this change to be RHEL6 material because of the kABI impact, or do we put effort into making a special workaround? (e.g. stack old values as we recurse, and replace on return; or add new interface only for dm and add hard-coding to block layer to use it) The 4.7 deadline has passed. As far as I am aware, the need for this is not large enough to justify the risk and effort to port this to 4.8. I will move this to RHEL 6. If there is enough demand, it is possible that we could consider this for RHEL 5, after it is upstream. Please open a separate BZ for that. Has this hit upstream yet? Sorry, I don't know. I'm just user, not programmer. If the question is about "merge" patches, these are in 2.6.27-rc. The lvm aligning to md chunk patches was just fixed in recent upstream lvm2 CVS. Considering that RHEL 6 will include recent upstreams of both kernel and LVM, setting this to MODIFIED. The feature requested has already been accepted into the upstream code base planned for the next major release of Red Hat Enterprise Linux. When the next milestone release of Red Hat Enterprise Linux 6 is available, please verify that the feature requested is present and functioning as desired. Does this mean that backporting to RHEL 5 is not currently on the list? Backporting kernel merge patches breaks kABI and workaround is not straightforward, so it is not planned for RHEL5 currently. Setting optimal readahead for dm stripe should be in RHEL5.2 lvm2 package already (see bug 423391) . (And using LVM over MD raid - LV aligning to MD chunksize by default will be in RHEL5.3 lvm2 package). This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |