all lists on 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal