Date: Wed, 18 Jun 2014 21:01:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 191173] New: Poor file write performance on xen blockfront Message-ID: <bug-191173-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191173 Bug ID: 191173 Summary: Poor file write performance on xen blockfront Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: netsqrl@gmail.com This bug report merely confirms the thorough benchmark done by Sydney Meyer summarized in his conversation with Roger Pau Monne here: http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/001951.html In my case the dom0 is NetBSD 6.1.4 with Xen 4.2. I noticed a few things that seems to be consistent with Sydney's observations: - With FBSD 10, dd-ing from /dev/zero into a file is at least 50% slower than dd-ing into a disk. In my case dd to file was ~25MB/sec at best, while dd to disk was ~60MB/sec. - With NetBSD domU run under HVM, dd-ing into a file was ~58MB/sec, dd-ing unto a partition was ~35MB/sec. Under NetBSD domU PV, it was 125+MB/sec - In the NetBSD dom0, dd-ing into a file was ~100MB/sec. In all case, each of the domU disks were backed by an LVM logical volume. NetBSD has/had some issue with poor domU disk write performance and basically, AFAIU, it's due to improper reordering of write requests. This email contains a patch that solved the problem (for NetBSD domU only, obviously), but you can read the whole thread. The NetBSD domU kernel that I use has this patch. I'm not a kernel programmer, so most of this stuff goes beyond my head, however, maybe the FreeBSD blockfront is suffering the same issue? Building an FBSD 10 kernel without PVHVM may give more data points, especially if the disk performs faster with the standard ide/sata/scsi driver (as is also shown in Sydney's email with FBSD 9.2). I just don't have the time ATM. Btw, the quickest way to repro the problem is to just use the installation cd, as you can get into the shell and mess around. DETAILS: * How the domU disk was setup: # gpart create ada0 # # Now boot part is created at offset 128k with size 128k. I suppose you can # # skip this for testing purposes, but it's here for illustration. # # In my case it is important because the domO disk is a raidframe # # (software raid) raid5 with 32k blocks, so it's best to start partition # # at multiple of 32k to avoid excessive read-modify-write. # gpart add -b 128k -s 128k -t freebsd-boot ada0 # gpart bootcode -p /boot/gptboot -i 1 ada0 # # Below is creation of ada0p2 # gpart add -b 1M -s 2047M -t freebsd-ufs ada0 # newfs -b 32k /dev/ada0p2 * How the dd into file was done # mount /dev/ada0p2 /mnt # cd /mnt # # Now write 1GB # dd if=/dev/zero of=big.img bs=32k count=$((1024*32)) * How the dd into disk was done # # Btw, I have a second disk /dev/ada1. I haven't tried this, but creating # # another partition might show the performance difference as well. # dd if=/dev/zero of=/dev/ada1 bs=32k count=$((1024*32)) Toby -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-191173-8>