lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 Apr 2010 13:41:51 -0700
From:	Brendan Cully <brendan@...ubc.ca>
To:	Tracy Reed <treed@...raviolet.org>,
	Pasi Kärkkäinen <pasik@....fi>,
	xen-devel@...ts.xensource.com,
	Aoetools-discuss@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] domU is causing misaligned disk writes

On Tuesday, 20 April 2010 at 13:00, Tracy Reed wrote:
> On Tue, Apr 20, 2010 at 11:49:55AM +0300, Pasi Kärkkäinen spake thusly:
> > Are you using filesystems on normal partitions, or LVM in the domU? 
> > I'm pretty sure this is a domU partitioning problem.
> 
> Also: What changes in the view of the partitioning between domU and
> dom0? Wouldn't a partitioning error manifest itself in tests in the
> dom0 as well as in the domU?
> 
> BTW: The dd from the last time in my last email finally finished:
> 
> # dd if=/dev/zero of=/dev/xvdg1 bs=4096 count=3000000
> 3000000+0 records in
> 3000000+0 records out
> 12288000000 bytes (12 GB) copied, 734.714 seconds, 16.7 MB/s
> 
> If I run that very same dd as above (the last test in my previous
> email) with the same partition setup again but this time from the
> dom0:
> 
> # dd if=/dev/zero of=/dev/etherd/e6.1 bs=4096 count=3000000
> 3000000+0 records in
> 3000000+0 records out
> 12288000000 bytes (12 GB) copied, 107.352 seconds, 114 MB/s
> 
> # /sbin/sfdisk -d /dev/etherd/e6.1 
> # partition table of /dev/etherd/e6.1
> unit: sectors
> 
> /dev/etherd/e6.1p1 : start=       64, size=566226926, Id=83
> /dev/etherd/e6.1p2 : start=        0, size=        0, Id= 0
> /dev/etherd/e6.1p3 : start=        0, size=        0, Id= 0
> /dev/etherd/e6.1p4 : start=        0, size=        0, Id= 0
> 
> Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz
> avgqu-sz   await  svctm  %util
> sda               0.00 17350.80  0.60 275.60    22.40 72540.00
> 525.43    97.94  344.01   3.62 100.02
> sdb               0.00 17374.80  1.20 256.00    28.00 74848.00
> 582.24   136.20  527.72   3.89 100.02

You could also be limited by the size of the block request ring (I
believe the ring is normally only one page) -- the ring needs to be
large enough to handle the bandwidth delay product, and AoE means the
delay is probably higher than normal. Do you get better performance
against a local partition?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ