http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1745
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@lists.xensource.com
ReportedBy: adi@cg.tuwien.ac.at
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
difference.
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
512.
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: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Xen-bugs mailing list
Xen-bugs@lists.xensource.com
http://lists.xensource.com/xen-bugs
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@lists.xensource.com
ReportedBy: adi@cg.tuwien.ac.at
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
difference.
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
512.
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: http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Xen-bugs mailing list
Xen-bugs@lists.xensource.com
http://lists.xensource.com/xen-bugs