The Linux kernel isn’t really much different between any distribution of Linux.

If it works on one, it works on the rest, in like 99% of cases.

The only real exception to that is custom distributions built specifically for a particular device or subset of devices.

In other words, for embedded devices, like phones, routers, TVs and such.

And those aren’t going to be running Ubuntu.

In my own experience, certain things should always be on their own dedicated machines.

My primary router/firewall is on bare metal for this very reason.

I do not want to worry about my home network being completely unusable by the rest of my family because I decided to tweak something on the server.

I could quite easily run OpnSense in a VM, and I do that, too. I run proxmox, and have OpnSense installed and configured to at least provide connectivity for most devices. (Long story short: I have several subnets in my home network, but my VM OpnSense setup does not, as I only had one extra interface on that equipment, so only devices on the primary network would work)

And tbh, that only exists because I did have a router die, and installed OpnSense into my proxmox server temporarily while awaiting new-to-me equipment.

I didn’t see a point in removing it. So it’s there, just not automatically started.

When people talk about CPU limitations on the rPi, they aren’t talking about just the actual processing portion of the machine. There are also a lot of other corners cut for basically all SBCs. Including bus width and throughput.

The problem is that when you use a software raid, like ZFS, or it’s precursors, you are using far more than the CPU. You’re also using the data bus between the CPU and the IO controller.

“CPU usage” indicators don’t really tell you how active your data buses are, but how active your CPU is, in having to process information.

Basically, it’s the difference between IO wait states, and CPU usage.

The Pi is absolutely a poor choice for input/output, period. Regardless of your “metrics” tell you, it’s data bus simply does not have the bandwidth necessary to control several hard drives at once with any sort of real world usability.

You’ve wasted your money on an entire ecosystem by trying to make it do something it wasn’t designed, nor has the capability, to do.

zfs list shows datasets.

zpool list shows pools.

mirror is a type of pool.

You sure that’s what is happening, and it’s not just mounting a different snapshot/dataset being mounted “on top” ?

I’ve seen it happen, which is why I ask. Assume the root dataset is named pool0 and has set0 set1 and set1/set2 as child datasets.

Their mount points are as follows:

/pool0/set0

/pool0/set1

/pool0/set1/set2

Now, if somehow, say set2 gets unmounted.temporarily, and you save files to /pool0/set1/set2 while the data set is not mounted, it’ll actually put those files in the set1 dataset, under the set2 directory.

But, when you mount the pool0/set1/set2 dataset again, the files under the set1 dataset are hidden by the set2 child.

Am I explaining it well enough for you to follow along?

Make sure you don’t have some similar situation by temporarily unmounting any nested datasets and ls’ing their mount points.

Damn, and I thought my 30k plus tracks was pretty large. I use Navidrome as a server and slskd as well

Hello fellow hass/mass user. Also, what sort of low voltage?

Fire/security alarms? Or access control? (Or both)?

I do both, as well as CCTV.

Real world usage tells me all I need to know.

SMB isn’t really all that slow these days.

I have NFS and SMB shares set up (same directory) and copying files to/from them maxes out my gigabit LAN.

SSH on the other hand is slower, because there’s more CPU overhead.

There’s also the slightly-less-hidden cost.

Electricity to run your home server(s).