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.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 23314 invoked from network); 15 Apr 2021 10:00:47 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 15 Apr 2021 10:00:47 -0000 Received: from mail-ed1-f44.google.com ([209.85.208.44]) by 1ess; Thu Apr 15 05:52:47 -0400 2021 Received: by mail-ed1-f44.google.com with SMTP id f8so27271226edd.11 for <9front@9front.org>; Thu, 15 Apr 2021 02:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Z5b/hTVDcnMq1+7+U3Nzwn39I9haUOBBxPkpJEefzNA=; b=jgUDbHQSZLjYSa/LAOkxt4CUqnC753b6bKWKL7ijrxHuKiuqZkv42kC7nPM6ynyT33 r70X6a0VagWIYhOdM0ZpkhiTYruZdL7EydsQjGYjSz8oU5fnbOXMPRD5JggCaPD7usuo m6+IaB4+vmaluD1P9KYW/BhOO8Xh5VmOVW5pKRGq+jFYtsdzqCSZwMH9X2NbXlMTEGpC +Pk2P7gGIOWMYdyyfRYkQ0tKqJCXCPEiNI8m4E1aNMIZoGI0pm+R60/dqLusHS+Vuut1 pdKzhhB//4vy+LOoA1SwLNuM/zWKaB7d3Fy07AncrbvBsCO1D5+ShoixbBIaxVnz2T7o Xe5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z5b/hTVDcnMq1+7+U3Nzwn39I9haUOBBxPkpJEefzNA=; b=jsXSoA4Bv/eclaMok5dLTrxXfKDi/LQBtKzigfkxmZEV0UNqIXvBHk29m2wWlyefUc 7QyFoiBf+xjXYtCO9cSKD2ZuYJlcIktNUEj3yVBJn6RsCqPU8lp9l7oNx03FGwtaFkF/ a2Rse4+4WmbWHwjUELEqOXzrQ/1jLKPYD1UL/oKFZkH1runCpd4G4KE8HISClaFAMmWD 72GUGAfJLAB6mdzMWajj6vWwHVNaldHKLNC0Fc5hTXWh3qsJXdsRFmE7KT1FkDZzVVa2 dKTYrT80mSn4gtF9lrctBBnoylc6jDoCLCMa8V7S/YGctwt02AxJCMIZLq3QzY4zlPMM 53RQ== X-Gm-Message-State: AOAM532Q0nBT5aPr+3x7cm/5+vEXPpcOGNVM/IrkWxvRJGKE6wWNQne3 dIqmb/jFvk/uti2yQhudAH/fZK1RmMxyOPU94aOZIpHv X-Google-Smtp-Source: ABdhPJzf3HBYnQ1npXerdZYaCGijavy3rnkqEnfYCjb96Bv075+HH/HSm4uMMz3ZzdVtezE0Oo/XkEMHCc/BZhBkEck= X-Received: by 2002:a05:6402:cb8:: with SMTP id cn24mr3112156edb.105.1618480357367; Thu, 15 Apr 2021 02:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:906:e98:0:0:0:0 with HTTP; Thu, 15 Apr 2021 02:52:36 -0700 (PDT) From: hiro <23hiro@gmail.com> Date: Thu, 15 Apr 2021 11:52:36 +0200 Message-ID: To: 9front <9front@9front.org> Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: webscale component YAML database browser Subject: [9front] vm disk performance Reply-To: 9front@9front.org Precedence: bulk i realized that my 9front KVM cwfs install assumes 512byte sectors. the physical disk actually uses 4k sectors. 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. these 2 things together might affect performance considerably, especially on hdds. 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 :) 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. 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. tests outstanding.