Oh yes, forgot to mention that.
I figured the same, therefore went ahead with the update on the production instance today.
Yet what I wrote today pertains to the production instance, actually… No /dev/null in sight here, only honest, hard working RRD files.
Checking the processes, it is the --create-rrd cmk process that is responsible for the load apparently, not the rrdcached itself or its updates to existing RRD files.
prod 1548 31.8 0.1 270580 134156 ? D 13:28 3:54 _ python3 /omd/sites/prod/bin/cmk --create-rrd --keepalive
Interesting enough, after enabling “log RRD creation → terse” I can see a lot of such lines:
2021-05-10 13:33:39 [4] [main] [RRD helper 1548] [log] Creating /opt/omd/sites/prod/var/check_mk/rrd/router101/Interface_VoIP-Null0.rrd
… so it seems it might be a one-time onslaught after the major upgrade, however long it may take? Although I’m wondering why the cmk process thinks it needs to create any of those RRD files in the first place, as they are already there. Also, disk usage for the /opt/ partition remains more or less unchanged, so there is indeed no such thing as a “RRD creation” actually happening.
Is this process misnamed maybe, and instead some kind of convert-rrds is happening instead? (I didn’t change any RRD parameters during upgrade, obviously)