From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 19:43:40 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7819B106566B for ; Mon, 2 May 2011 19:43:40 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3B6B8FC17 for ; Mon, 2 May 2011 19:43:39 +0000 (UTC) Received: by fxm11 with SMTP id 11so5616326fxm.13 for ; Mon, 02 May 2011 12:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oIaKAzilSVWKuqFI+7YhRpYiFCFR6gxG6c6I9pKBw38=; b=J1O9CNOqqb5l47p+eRrjeTQx1kzy+4dFqPMCyLVRPlQfvgQdzDNN3RYuOzb2r7OhKj Y0JPHGzyLARCvGcEObcUAzsfNP3fL4asZ1UT5wwMC6I/e408O3jMPhFc9dHATBaBHbJ5 a/E8Mk49+Jwb5y5geyF6xVKwBKUTp284/4548= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fyvyBZCID7vlZukftitSmaHsI1nHfFK2h91+xmofF0CyKeXZYzmlIfSSdSTjsU6aQX C3+U30SQlr07+1nkfWZNvP2CBCWIR6NF32tZ6dqFKgkS75+CyvBbaYqhBar8wXyPQTbs JoMzXpBP/zT9e/05vzw29wCarbPj0xde2OmCs= MIME-Version: 1.0 Received: by 10.223.54.213 with SMTP id r21mr1435225fag.54.1304365418487; Mon, 02 May 2011 12:43:38 -0700 (PDT) Received: by 10.223.20.145 with HTTP; Mon, 2 May 2011 12:43:38 -0700 (PDT) In-Reply-To: <4DBEFBD8.8050107@mittelstaedt.us> References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> Date: Mon, 2 May 2011 14:43:38 -0500 Message-ID: From: Adam Vande More To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 19:43:40 -0000 On Mon, May 2, 2011 at 1:45 PM, Ted Mittelstaedt wrote: > On 5/2/2011 5:09 AM, Adam Vande More wrote: > >> On Mon, May 2, 2011 at 12:54 AM, John wrote: >> >> On both the FreeBSD host and the CentOS host, the copying only takes 1 >>> second, as tested before. Actually, the classic "dd" test is slightly >>> faster on the FreeBSD host than on the CentOS host. >>> >>> The storage I chose for the virtualbox guest is a SAS controller. I >>> found >>> by default it did not enable "Use Host I/O Cache". I just enabled that >>> and >>> rebooted the guest. Now the copying on the guest takes 3 seconds. >>> Still, >>> that's clearly slower than 1 second. >>> >>> Any other things I can try? I love FreeBSD and hope we can sort this >>> out. >>> >>> >> Your FreeBSD Host/guest results seem relatively consistent with what I >> would >> expect since VM block io isn't really that great yet, however the results >> in >> your Linux VM seems too good to be true. >> > > We know that Linux likes to run with the condom off on the file system, > (async writes) just because it helps them win all the know-nothing > benchmark contests in the ragazines out there, and FreeBSD does not > because it's users want to have an intact filesystem in case the > system crashes or loses power. I'm guessing this is the central issue > here. > > > Have you tried powering off the >> Linux VM immediately after the cp exits and md5'ing the two files? This >> will insure your writes are completing successfully. >> >> > That isn't going to do anything because the VM will take longer than 3 > seconds to close and it it's done gracefully then the VM won't close until > the writes are all complete. No, this is no correct. You can kill the VM before it has a chance to sync(in Vbox, the poweroff button does this, and the qemu/kvm stop command is not a graceful shutdown either). I haven't actually tested this, but it would seem to be a large bug if doesn't work this way since there are also graceful shutdown options in both hypervisors and the documenation states you may lose data with this option. If nothing else, the real power cord will do the same thing. > http://ivoras.sharanet.org/blog/tree/2009-12-02.using-ministat.html >> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023435.html >> >> > However that tool doesn't mimic real world behavior, either. That tool is for analyzing benchmarks, not running them. > The only > real way to test is to run both systems in production and see what > happens. > Any dev/testing environment I setup or worked with has a method for simulating extremely bad scenarios production might face like 10,000 devices phoning home at once to an aggregation network, with an equally severe load coming from the web frontend. I thought this was pretty common practice. I would not make a choice of going with one system over another based > on a single large file write difference of 2 seconds. We have to > assume he's got an application that makes hundreds to thousands of large > file writes where this discrepancy would actually make a difference. > >From the information given, that's not an assumption I'm comfortable with. OP will have to find his own way on that whether it's something like blogbench or bonnie or "real data" with real data being the best. Agreed that discrepancy surely would make a difference if it's consistent across his normal workload. However, there are many cases where that might not be true. -- Adam Vande More