This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-bugs] [Bug 1745] New: blk[front|back] does not hand over disk param

To: xen-bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-bugs] [Bug 1745] New: blk[front|back] does not hand over disk parameters
From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
Date: Fri, 25 Feb 2011 08:29:54 -0800
Delivery-date: Fri, 25 Feb 2011 08:30:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-bugs-request@lists.xensource.com?subject=help>
List-id: Xen Bugzilla <xen-bugs.lists.xensource.com>
List-post: <mailto:xen-bugs@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=unsubscribe>
Reply-to: bugs@xxxxxxxxxxxxxxxxxx
Sender: xen-bugs-bounces@xxxxxxxxxxxxxxxxxxx

           Summary: blk[front|back] does not hand over disk parameters
           Product: Xen
           Version: unspecified
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Linux-pv_ops domU
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: adi@xxxxxxxxxxxxxxx

System details:
Debian Squeeze with Xen 4.0.1 and kernel 2.6.32 (both from Debian). Guest
system is Squeeze as well. Using 32/64bit Dom0/DomUs does not make any

when exporting a RAID6 wrapped in LVM via phy:// to a domU write performance is
(very) bad due to wrong disk parameters:
Dom0 does not export very important parameters to DomU:
On Dom0 (RAID6 with 8 disks):
blockdev --getiomin /dev/space/test
524288 (which is chunk size)
blockdev --getioopt /dev/space/test
3145728 (which is 6*chunk size)

on DomU:
blockdev --getiomin /dev/xvdb1
512 (which corresponds to the block size that is set to 512 in
xlvbd_init_blk_queue (blkfront.c))
blockdev --getioopt /dev/xvdb1
0 (which means the kernel will use 1MB by default)

And 'blockdev --getbsz /dev/space/test' gives 4096 on Dom0 while DomU reports

The lack of correct setting of these parameters leads to a very bad write rate
(30MB/s in DomU while Dom) manages to write with around 130MB/s.
The issue is noticeable when watching iostat output in Dom0: there will be many
reads while writing but only on the disks part of the RAID6 not the raid device
itself. This is caused by recalculation of the stripes due to imperfectly
aligned writes: a stripe has (in my case) 3MB of size whereas only 1MB will be
written at a time. So for writing 3MB, it is necessary to recalculate the
parity blocks 3 times plus reread the missing 2MB to do so 3 times as well --
though, I guess this will live on in the cache as I see a read rate between
17-25MB/s while write rate is at 40MB/s.

Configure bugmail: 
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Xen-bugs mailing list

<Prev in Thread] Current Thread [Next in Thread>