From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26894 invoked from network); 16 Apr 2021 09:24:28 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2021 09:24:28 -0000 Received: from mail-io1-f51.google.com ([209.85.166.51]) by 1ess; Thu Apr 15 21:04:58 -0400 2021 Received: by mail-io1-f51.google.com with SMTP id a11so24027930ioo.0 for <9front@9front.org>; Thu, 15 Apr 2021 18:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=AWiithFHAHxAFo+nKjK99sEXlF39ZuwnLeXBHpBajyg=; b=aW0kEwK30Sj/LDz6N10OBglfoRThEysxEgCLhyqApXOV7AIPJRpmBqGyzwcs+Yk4eT cAIqgqQUZB8XYu1T96wdLRfTqHoBAG+UaFFXUIsaDmWfyqw3hSmCLUwtgSllZsCCJFrO RIReoxqnyjdxsne6OhrEoXv22FsIqBqtvcxJ+MFGNZlUj4yOLCBbLsjppwwsALHhevdf XhcP9xbfbp7cIikgGCkHTnk0xi+oR8vvVzBnmcmkB2nXBH9y53ioJ4rLZIAonU76F9oX O14CNJdr9+UQiymhq8nJx6RNj8urMhYIUwJHPDfrgemRWzdCdLKfG8m6NgEoqnLxkfVF Qjhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=AWiithFHAHxAFo+nKjK99sEXlF39ZuwnLeXBHpBajyg=; b=W2bwDGWkpCZF2hkwr+N6d0p5hFZOFITK6xgr6O4azK0CvcsjP81MaY6A3pscEFbKpP yVJwvybu4KwB69IwjytwF47ivX56lDx9U0DFpjUYPSBNDBKYD4vw+ur9GyX40V26X5ke IONEp6ht++Y8HL0Rlol9nmUayjwQXn9OlG7uBq7T/L+wrTwyxTb90OHk+RgJ6OLL9IP8 +FVqvh3+iYyBmBOcU6FvHHvi87zTn7kqjkMVXR3r5LRwy1PXWd/QNyXbCrC33uIFq5ai dyuOV2luUlPNo7Q7dVWpfwFfTUUDzgMxTkUfO9lZfejL+5B82MVfbTF9INbX5j61iqCG i3/Q== X-Gm-Message-State: AOAM532bdcJa+bvmpCzMB+soiZ8IedxpFIsK177pnpkAD0zgrqPjqU6h r8T9ixKtqE3aQRtYQayB0STOPe/jN58= X-Google-Smtp-Source: ABdhPJxv6VM3pX0fnl156KVGhryKctv0GNgcS71ULJMG+1ZzbIPPtoZ6t+F4Fih7SrV/mSJGjINvCg== X-Received: by 2002:a02:1c81:: with SMTP id c123mr1882785jac.42.1618535088963; Thu, 15 Apr 2021 18:04:48 -0700 (PDT) Return-Path: Received: from [10.0.1.7] (c-67-184-39-205.hsd1.il.comcast.net. [67.184.39.205]) by smtp.gmail.com with ESMTPSA id m5sm1993233ilg.79.2021.04.15.18.04.47 for <9front@9front.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Apr 2021 18:04:48 -0700 (PDT) From: Xiao-Yong Jin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 15 Apr 2021 20:04:46 -0500 References: To: 9front@9front.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: anonymous anonymous cloud-based framework Subject: Re: [9front] vm disk performance Reply-To: 9front@9front.org Precedence: bulk > On Apr 15, 2021, at 4:52 AM, hiro <23hiro@gmail.com> wrote: >=20 > i realized that my 9front KVM cwfs install assumes 512byte sectors. > the physical disk actually uses 4k sectors. >=20 > the partition table also aligns things by sector size. > until nvram we are aligned by big enough multiples of 512 that they > happen to also be multiples of 4k. > but nvram is one sector big, causing the next important partition > (other) to be misaligned by those 512bytes. >=20 > these 2 things together might affect performance considerably, > especially on hdds. >=20 > personally i also use zvols from zfs between the VMs and my disk, they > also happen to have a blocksize, the rather low default should > generally be increased to 16k to align with cwfs. even though i doubt > anybody else here is using zvols :) % zfs list -o = space,type,compress,compressratio,volmode,volsize,volblocksize = zroot/9front =20 NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD = TYPE COMPRESS RATIO VOLMODE VOLSIZE VOLBLOCK zroot/9front 353G 45.9G 5.96G 15.1G 24.9G 0 = volume lz4 1.46x dev 30G 8K > i remember also a long time ago i discovered (on shady forums, don't > remember) that kvm on linux by default forces all normal (async) > writes to the virtual disk for "legacy" operating systems to by > synchronous to protect us from ourselves. > personally i disabled sync writes on my zfs as a good enough remedy, > but i have *no clue* how much better it might work if kvm could be > convinced we are a microsoft/redhat certified non-legacy system. >=20 > since i managed to find already 4 very probable big bottlenecks for > common setups with 9front inside VMs, i'd like to share my preliminary > view on this matter. >=20 > tests outstanding. I never worried about performance here, because network latency = dominates most of the use cases. Perhaps you may produce some benchmarks for a couple of use cases in mind?