Looks like it has an ARM CPU, a RK3588. Similar ballpark to a Pi 5 in CPU performance.

Installing another OS would be technically possible but not easy, you’d need a Linux kernel with the RK3588 drivers already in it. Then there are differences between it and other RK3588 SBCs that could cause problems.

Much like you wouldn’t want to install anything other than raspbian on a Pi, you’d be best off with ugreen’s OS even if others are technically possible.

I fucking love copyparty. It starts simple enough but then the millions of options and configs let you twist it into exactly what you need.

As someone that runs a server OS that doesn’t support docker, it is very refreshing to see a single binary project. It has a focus on being administrator friendly thats really fallen out of fashion these days.

Ah kay, definitely not a RAM size problem then.

iostat -x 5 Will print out per drive stats every 5 seconds. The first output is an average since boot. Check all of the drives have similar values while performing a write. Might be one drive is having problems and slows everything down, hopefully unlikely if they are brand new drives.

zpool iostat -w Will print out a latency histogram. Check if any have a lot above 1s and if it’s in the disk or sync queues. Here’s mine with 4 HDDs in z1 working fairly happily for comparison:

The init_on_alloc=0 kernel flag I mentioned below might still be worth trying.

deleted by creator

After some googling:

Some Linux distributions (at least Debian, Ubuntu) enable init_on_alloc option as security precaution by default. This option can help to prevent possible information leaks and make control-flow bugs that depend on uninitialized values more deterministic.

Unfortunately, it can lower ARC throughput considerably (see bug).

If you’re ready to cope with these security risks 6, you may disable it by setting init_on_alloc=0 in the GRUB kernel boot parameters.

I think it’s set to 1 on Raspberry Pi OS, you set it in /boot/cmdline.txtI think.

Exhaustive ZFS performance tuning guide

sync=disabled will make ZFS write to disk every 5 seconds instead of when software demands it, which maybe explains your LED behavior.

Jeff Geerling found that writes with Z1 was 74 MB/sec using the Radxa Penta SATA HAT with SSDs. Any HDD should be that fast, the SATA hat is likely the bottleneck.

Are you performing writes locally, or over smb?

Can try iostat or zpool iostat to monitor drive writes and latencies, might give a clue.

How much RAM does the Pi 5 have?