Atemu

Isn't that the cloud shit?

Why is it that GrapheneOS/CalyxOS always seem to attract these kinds of people?

I somehow doubt that's all you said.

Well, unlike us, they're obviously living in a country which massively subsidises energy cost. But it seems they either haven't done the math properly or their measuring device is broken because even they shouldn't be paying pennies per month.

You can do the calculation for yearly cost yourself; it's not too hard. The two variables you need are energy pice and power.

Let's say you've got 30W idle power draw at 0.4€/kWh. That comes out to ~105€/year if you ran it 24/7.

You can plug in arbitrary values yourself: https://numbat.dev/?q=1+year++30W++%280.4%E2%82%AC%2FkWh%29%E2%8F%8E

Unless you have specific needs for compute, I'd go with that.

You really ought to look into idle power though. At $0.1/kWh, 1W is about $1/year. You can extrapolate from there.
TDP doesn't matter here but the i3 is likely more efficient under load.

The shipping cost is quite extreme though. Not sure I'd pay that.

It's not the mixing that's bad, it's using USB in any kind of multi-device setup or even using USB drives for active workloads at all.

The problem is on the logic level. What happens when a drive drops out but the other does not? Well, it will continue to receive writes because a setup like this is tolerant to such a fault.

Now imagine both connections are flakey and the currently available drive drops out aswell. Our setup isn't that fault tolerant, so FS goes read-only and throws IO errors on read.
But, as the sysadmin takes a look, the drive that first dropped out re-appears, so they mount the filesystem again from the other drive and continue the workload.

Now we have a split brain. The drive that dropped out first missed the changes that happened to the other drive. When the other drive comes back, they'll have diverged states. Btrfs can't merge these.

That's just one possible way this can go wrong. A simpler one I allured to is a lost write where a drive will claim to have permanently written something but if power was cut at that moment and the same sector read upon restart, it will not actually be the new data. If that happens to all copies of a metadata chunk, good bye btrfs.

I got a tiny Lenovo M720Q (i5-8400T / 8RAM / 128NVME / 1Tb 2,5" HDD) that I want to set as my home server with the ability to add 2 more drives (for RAID5 if possible) later using its two USB 3.1 Gen 2 (10gbps).

Do not use USB drives in a multi-device scenario. Best avoid actively using them at all. Use USB drives for at most daily backups.

I wouldn't advocate for RAID5. I'd also advocate against RAID to begin with in a homelab setting unless you have special uptime requirements (e.g. often away from home for prolonged periods) or an insane amount of drives.

I will mostly use 40/128GB of its capacity with no idea how to make use of the rest.

I use spare SSD space for write-through bcache. You need to make the decision to use it early on because you need to format the HDDs with bcache beneath the FS and post-formatting conversions are hairy at best.

most of what I read online predate kernel 6,2 (which improved BTRFS RAID56 reliability).

Still unstable and only for testing purposes. Assume it will eat your data.

With btrfs I would set up a regular scrubbing job to find and fix possible data errors automatically.

This only works for minor errors caused by tiny physical changes. A buggy USB drive dropping out and losing writes it claimed to have written can kill a btrfs (sometimes unfixably so) especially in a multi-device scenario.

Note how I said that it's never good. Being proprietary might not be bad in some cases but it's never good either.

That's all there really is. It's easy enough to just try these. I've been looking to set up a local piped instance but the android app still needs some work.

I'm not aware of any other usable tool worth using apart from yt-dlp'ing everything and watching locally I guess?

It's proprietary I guess? That's never good.