Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 466088

Summary: dm-snapshot: very slow write to snapshot origin when copy-on-write occurs
Product: Red Hat Enterprise Linux 5 Reporter: Kazuo Ito <ito.kazuo>
Component: kernelAssignee: Mikuláš Patočka <mpatocka>
Status: CLOSED ERRATA QA Contact: Boris Ranto <branto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1CC: agk, bdonahue, branto, mbroz, msnitzer
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 20:43:48 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:

Description Kazuo Ito 2008-10-08 09:02:27 UTC 
Description of problem:

Write to snapshot origin volumes, iff copy-on-write occurs,
are an order of magnitude slower than the other lvm writes.
The slowdown is more pronounced in cases of sequential writes.

A couple of measures to alleviate the problem have been floating
around the net, 1) to make snapshot origin and cow volumes
reside on separate disks, and 2) to patch kcopyd so that
it shouldn't reorder block write requests when process_jobs
fails to complete them because it run short of free pages.

I ran several tests and found that the patch (see attachment)
can make copy-on-write cases twice as fast as the non-patched kernel,
and, as a side note, that allocating more pages to kcopyd clients
does not help much.

Version-Release number of selected component (if applicable):

How reproducible:

Always.

Steps to Reproduce:
1. create a file on an LV, e.g. dd if=/dev/zero of=<path to the file> bs=4096 count=10240
2. create a snapshot of the volume
3. overwrite the file, e.g. dd if=/dev/zero of=<path to the file> \
  bs=4096 count=10240 conv=notrunc, followed by fsync
4. overwrite the file again, followed by fsync
  
Actual results:

3. is x10 -- x20 slower than 4.

Expected results:



Additional info:
Comment 1 Kazuo Ito 2008-10-24 02:56:48 UTC 
An upstream patch for the problem has been queued in the 2.6.27-stable tree.
( http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=commit;h=576197a5ec84bde5889d4ac0df69aa427aa61f48 )

Its filename is dm-kcopyd-avoid-queue-shuffle.patch.
Comment 3 Mikuláš Patočka 2010-05-18 21:54:46 UTC 
I think this patch could be ported to RHEL 5.6. It is simple and obviously correct.
Comment 4 RHEL Program Management 2010-05-20 12:48:12 UTC 
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 6 Jarod Wilson 2010-09-21 20:58:53 UTC 
in kernel-2.6.18-223.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.
Comment 10 errata-xmlrpc 2011-01-13 20:43:48 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html