[xoa]

>It's said to be a good fit for ZFS. I tend to lz4 because its baked into the older systems I use, but it may be at a point where my default should be zstd.

It is, and you should definitely at least give it a look. I posted a comment mentioning it the other day in the OpenZFS 2.0 thread [0], and it also came up recently on HN in a thread linked there, but there are some interesting performance graphs comparing different standards in the github PR for zstd in ZFS [1]. LZ4 still has its place IMO, ZFS is not run nor good for exclusively heavier metal, people use it to good effect on the likes of things like RPis as well. Sometimes CPU cycles is still the limiter or every last one is needed elsewhere. I also think it matters a lot less on spinning rust, where $/TB tends to be so much lower. How much one gets out of it also is influenced by application, general NAS with larger record size is going to see different gains vs a database. But with even vaguely modern desktop CPUs (and their surfeit of cores) and SSDs, particularly in network storage dedicated devices, an extra 10-30% even is worth a lot and there's usually plenty of CPU to throw at it. Even more so if primary usage is limited to only a 10-50 Gbps connection.

As always though probably best if you can benchmark it with your own stuff and play around a bit pulling different levers. ZFS is nice that way too since it's so easy to create a bunch of different test FS at the same time.

----

0: https://news.ycombinator.com/item?id=29268907

1: https://github.com/openzfs/zfs/pull/9735#issuecomment-570082...

[ggm]

rpi4 8GB with the radxa USB-bridged 4 port card. 4x 2TB HDD. I couldn't afford SSD. Its Ubuntu ZFS. Not over-performant, but does the job. I run a single disk ZFS detachable for periodic snapshots. Really? I like the belt-and-braces aspect of this one. 4 disks should be reasonably safe for single disk failure and I have a snap monthly, albiet all on one platter. Not enterprise-grade safe, but good-enough.

There's enough grunt left over to be my plex headend as well as long as I avoid transcoding.

I actually wanted to run FreeBSD on it, but the rpi4 wasn't fully ported when I started. In the back of my mind, it should be "safe" to convert over because OpenZFS. Which is kind-of the point.

I avoided de-dup. It burns your CPU. But I think compression is worth it, even with a lot of mp4 and mp3 and jpg content (photo and live-TV PVR archives, aside from music)

There's a lot of FUD about ZFS on small devices, how much memory you "need" -I think something said of Solaris got conflated up into a ZFS "law" about minimum memory for the ARC which just isn't really true: it may not be performant, but it works fine on smaller memory (than 8gb) systems. I chose the 8GB pi4 because I could afford it. I would have been fine on 4GB.

[vermaden]

I have run 2 x 2 TB ZFS mirror on 512 MB machine with FreeBSD for years along with compression enabled and also other services running like Samba/NFS/Syncthing/Nextcloud/... and it worked like a charm. The only time when this machine rebooted when I needed to apply security updates for the kernel or when there was power outage as it did not had UPS backup power.

The RAM requirement for ZFS is one of the biggest myths of ZFS.

If you have lots of RAM then great - ZFS can use it as cache with ARC.

Otherwise its just as fast as disks on which its running - like every other filesystem.

The other 'big' myth about ZFS is ECC requirement - which is of course not true.

ECC RAM is useful for ALL FILESYSTEMS - not just only for ZFS.

But from all filesystems ZFS works best of all when you do not have ECC RAM.

Regards.