9front - general discussion about 9front
 help / color / mirror / Atom feed
From: hiro <23hiro@gmail.com>
To: 9front <9front@9front.org>
Subject: [9front] vm disk performance
Date: Thu, 15 Apr 2021 11:52:36 +0200
Message-ID: <CAFSF3XNXBwnN-Xx6_Wwyo7LpAVW=rT_js92jv6KCd75-miuzHA@mail.gmail.com> (raw)

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.

             reply	other threads:[~2021-04-15 10:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15  9:52 hiro [this message]
2021-04-16  1:04 ` Xiao-Yong Jin
2021-04-16 12:31   ` hiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFSF3XNXBwnN-Xx6_Wwyo7LpAVW=rT_js92jv6KCd75-miuzHA@mail.gmail.com' \
    --to=23hiro@gmail.com \
    --cc=9front@9front.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git