[pve-devel] avoidable writes of pmxcfs to /var/lib/pve-cluster/config.db ?

[Roland]

>> 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