If you have a server with out-of-band/lights-out management such as iDRAC (Dell), iLO (HPe), IPMI (generic, Supermicro, and others) or equivalent, those can measure the server’s power draw at both PSUs and total.

I think you’re asking too much from ZFS. Ceph, Gluster, or some other form of cluster native filesystem (GFS, OCFS, Lustre, etc) would handle all of the replication/writes atomically in the background instead of having replication run as a post processor on top of an existing storage solution.

You specifically mention a gap window - that gap window is not a bug, it’s a feature of using a replication timer, even if it’s based on an atomic snapshot. The only way to get around that gap is to use different tech. In this case, all of those above options have the ability to replicate data whenever the VM/CT makes a file I/O - and the workload won’t get a write acknowledgement until the replication has completed successfully. As far as the workload is concerned, the write just takes a few extra milliseconds compared to pure local storage (which many workloads don’t actually care about)

I’ve personally been working on a project to convert my lab from ESXi vSAN to PVE+Ceph, and conversions like that (even a simpler one like PVE+ZFS to PVE+Ceph would require the target disk to be wiped at some point in the process.

You could try temporarily storing your data on an external hard drive via USB, or if you can get your workloads into a quiet state or maintenance window, you could use the replication you already have and rebuild the disk (but not the PVE OS itself) one node at a time, and restore/migrate the workload to the new Ceph target as it’s completed.

On paper, (I have not yet personally tested this), you could even take it a step farther: for all of your VMs that connect to the NFS share for their data, you could replace that NFS container (a single point of failure) with the cluster storage engine itself. There’s not a rule I know of that says you can’t. That way, your VM data is directly written to the engine at a lower latency than VM -> NFS -> ZFS/Ceph/etc

My server rack has

• 3x Dell R730
• 1x Dell R720
• 2x Cisco Catalyst 3750x (IP Routing license)
• 2x Netgear M4300-12x12f
• 1x Unifi USW-48-Pro
• 1x USW-Agg
• 3x Framework 11th Gen (future cluster)
• 1x Protectli FE4B

All together that draws… 0.1 kWh… in 0.327s.

In real time terms, measured at the UPS, I have a running stable state load of 900-1100w depending on what I have at load. I call it my computationally efficient space heater because it generates more heat than is required for my apartment in winter except for the coldest of days. It has a dedicated 120v 15A circuit

I get what you’re trying to get at here - but counterpoint: a lot of sites offer very long or infinitely scrolling pages. Getting rid of stuff you’ve scrolled past or wont scroll to for a while makes the page not a memory leak. So specifically for Discourse, New Reddit, Discord, Facebook, Twitter, Bluesky, and all those family of pages, if you do manage to succeed you will turn the page into a memory leak. And it’s going to lag your renderer if those objects aren’t unloaded.

OT but am I the only one that noticed the fox’s headphones aren’t on their ears?