With 4GB of RAM, you'd even be able to use ZFS.
- 1Gbit ethernet
- 1Gbit USB 3.0 port 1
- 1Gbit USB 3.0 Port 2
Total: 3Gbit of 4Gbit, having some margin to spare.
1 Gbit Ethernet over RGMII
4 Gbit PCIe Gen 2 shared by 2 USB 3.0 (so 1x 4 gbps max or 2 x 2 Gbps shared)
Total: 5 Gbits, no margin to spare
Only if both drives are saturated at the same time. But since the context here is a NAS usage, there's a max 1gbps upstream/downstream in the first place so you could comfortably do a 4 drive mirror NAS off of this and not have any bottlenecks on the USB 3.0 -> SATA side of things.
Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems (those that do not try to correct errors on the fly like ZFS).
> There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
[0] https://arstechnica.com/civis/viewtopic.php?p=26303271#p2630...
Ooooo, I hadn't heard about that one. I have one non-ECC box running ZFS where I might want to enable this. If the performance impact is negligible, it'd be worth trying.
Assuming a memory error somewhere:
On ZFS you'd be writing bad data with a bad checksum, which would be caught by ZFS later on.
On (most) other filesystems you'd be writing bad data and no checksum, and you'd be none the wiser until garbage comes back.
It's a myth that ZFS requires ECC memory; ZFS is safer when running with ECC, but without ECC it will still save your data in a lot of places where most other filesystems won't.
See https://www.reddit.com/r/zfs/comments/7ng231/does_a_zfs_mirr... for a bunch of links on this.
Edit: To add on to this, ZFS doesn't do parity-based repair at the checksum level. In the mentioned case (good data, bad checksum) no copy of the block will match the checksum and there will be no supposedly-good block to copy over.
Only difference is that other filesystems may have better tools to rescue damaged filesystem after metadata is corrupted.
Though as you have the 3b+, then you have none of that dilemma and it will just boot, done it myself.