public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Roland <devzero@web.de>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] avoidable writes of pmxcfs to /var/lib/pve-cluster/config.db ?
Date: Wed, 10 Mar 2021 09:18:36 +0100	[thread overview]
Message-ID: <39c0fe3b-8261-8477-e501-f728bcb4c051@web.de> (raw)
In-Reply-To: <3463e859-a6d9-ea66-481e-4f7548306e7d@proxmox.com>


>> corruption in particular problem situations like server crash or whatever.
> So the prime candidate for this write load are the PVE HA Local Resource
> Manager services on each node, they update their status and that is often
> required to signal the current Cluster Resource Manager's master service
> that the HA stack on that node is well alive and that commands got
> executed with result X. So yes, this is required and intentional.
> There maybe some room for optimization, but its not that straight forward,
> and (over-)clever solutions are often the wrong ones for an HA stack - as
> failure here is something we really want to avoid. But yeah, some easier
> to pick fruits could maybe be found here.
>
> The other thing I just noticed when checking out:
> # ls -l "/proc/$(pidof pmxcfs)/fd"
>
> to get the FDs for all db related FDs and then watch writes with:
> # strace -v -s $[1<<16] -f -p "$(pidof pmxcfs)" -e write=4,5,6
>
> Was seeing additionally some writes for the RSA key files which should just
> not be there, but I need to closer investigate this, seemed a bit too odd
> to
> me.
not only these, i also see constant rewrite of  (non-changing?) vm
configuration data , too.

just cat config.db-wal |strings|grep ..... |sort | uniq -c   to see
what's getting there.

the weird thing is, that it does not happen for every VM. just some. i
send you an email with additional data (don't want to post all my VMs
mac adresses in public)

>
> I'll see if I can find out a bit more details about above, maybe there's
> something to improve lurking there.
>
> FWIW, in general we try to keep stuff rather simple, the main reason is that
> simpler systems tend to work more reliable and are easier to maintain, and
> the load of even simple services can still get quite complex in sum, like
> in
> PVE; But we still try to avoid efficiency trade offs over oversimplification.


thanks for explaining , for the hints how to trace writes and for having
a look.

sure, critical components SHOULD be simple!

roland







  reply	other threads:[~2021-03-10  8:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 20:45 Roland
2021-03-10  6:55 ` Thomas Lamprecht
2021-03-10  8:18   ` Roland [this message]
2021-03-10  9:08     ` Thomas Lamprecht

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=39c0fe3b-8261-8477-e501-f728bcb4c051@web.de \
    --to=devzero@web.de \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal