Hello,

 

Would just like to query the hivemind regarding which filesystem to use on a new array. The info that will hopefully be useful into giving that advice is below.

 

• Will start small with a single parity (18TB) and two data drives (16TB), then add over time as needed
• A number of smaller SSDs (256GB) will likely be used as a cache pool
• Will have some sort of backup strategy for critical data, involving various USB drives, TBD
• Single user (homelab) so multi-user stuff isn't important. It might or might not stay on 24x7 but intend to configure so drives spin down after a period of inactivity.

 

The main aspect is that I'll be using encryption. Although the documentation cautions regarding that due to "complexity" with resolving some situations, I don't consider it optional. We're not talking nation-state stuff here, just basicially given it'll host at least an Immich instance and backups of local myDocuments type data, it's important that if the box gets stolen or something and ends up in the hands of someone vaguely competent, that they don't have an easy route to just grab all the data.

 

Given the above, it seems like the following are the options:

1. xfs - encrypted
2. zfs - encrypted (the native support in v7)

 

I would lean towards zfs, unless there's some compelling reason to stick to the existing xfs, and that's where I'm hoping the folks here would have some insight. I haven't been able to find much detail around the specifics, and a lot of it pertains to v6 and previous before the native support was added. Like I've seen mentions about adding new drives being more complex with zfs, but I'm unclear about the details of why, or if that's even relevant with the native support.

 

Will appreciate any advice people have, thank ya'll.

ZFS in the Unraid type array does not perform very well - it is fine in a pool.    If in the main Unraid type array then either ZFS or BTRFS are fine.

8 hours ago, itimpi said:

If in the main Unraid type array then either ZFS or BTRFS are fine

Sure this isn't a typo ?

I bet you wanted to say XFS instead of ZFS...

 

Thanks both, appreciate the inputs. With regards to the issues using zfs in an array, is that a performance issue in terms of speed, or some kind of feature of the filesystem that doesn't work when used in that way?

 

Sounds like xfs - encrypted might be the way to go for the array, and I'd probably go with btrfs - encrypted for the cached, would presume it defaults to that for good reasons.

 

Another slightly related question, is there any difference in the process with rebuilding from a failed drive when using encrypted filesystem? The docs mention that there can be issues recovering from "certain kinds" of hardware failure, but I haven't found much information about what kinds those are and what works differently or less effectively in those circumstances.

 

Thank you

Edited April 21, 20251 yr by havet24069

13 minutes ago, havet24069 said:

With regards to the issues using zfs in an array, is that a performance issue in terms of speed, or some kind of feature of the filesystem that doesn't work when used in that way?

Depends on how much you are able to suffer. "Speed" drops down to below 6Mb/s sometimes, depending on the amount of zfs disks in the Unraid array. It can even lead to a full stop under bad conditions.

This is because ZFS is "clever and self-healing and self-optimizing". If there is nothing to do, it cleans up free blocks, rearranges (defrags) files and so on.

 So far, so good. But of course, this causes serious write operations. Normally (in a pool) you do not notice them at all because ZFS knows that it has spare time. But in an UNRAID array, the parity drive(s) sit on top and have to follow each write. And if ZFS 1 sends the head to track #34, ZFS 2 sends it to #1234 and ZFS x sends it to the moon, you can imagine what stress it creates on the parity drive (and the other drives in the array depending on the write mode that you have selected). If idle such a array may skyrocket! And of course, if YOU then want something from it, there is no IO time left...

 

So stay away from ZFS in the array for now (they say they are working on it, but I can hardly think how this situation can be overcome by the filesystem on top of the array...)

 

Edited April 21, 20251 yr by MAM59

4 hours ago, MAM59 said:

This is because ZFS is "clever and self-healing and self-optimizing". If there is nothing to do, it cleans up free blocks, rearranges (defrags) files and so on.

 So far, so good. But of course, this causes serious write operations. Normally (in a pool) you do not notice them at all because ZFS knows that it has spare time. But in an UNRAID array, the parity drive(s) sit on top and have to follow each write. And if ZFS 1 sends the head to track #34, ZFS 2 sends it to #1234 and ZFS x sends it to the moon, you can imagine what stress it creates on the parity drive (and the other drives in the array depending on the write mode that you have selected). If idle such a array may skyrocket! And of course, if YOU then want something from it, there is no IO time left...

Thank you for this splendid explanation. There's nothing I specifically need in zfs, it was just a case of "unless there's a compelling reason, might as well use it". But you have indeed highlighted a very specific reason to go in a different direction and I'll definitely be following that advice.

 

Hopefully someone can weigh in on the query about the encrypted drives, but I consider the original question completely addressed and am grateful for the time and advice of both MAM59 and itimpi in this. Very glad I asked ahead and saved some pain down the line!

 

Many thanks.

12 minutes ago, havet24069 said:

Hopefully someone can weigh in on the query about the encrypted drives

Sorry, I am out with that. I never understood why somebody wanted that. Its very unlikely that somebody can break into my computer room and steal a disk. Its much more likely that I forget the password (-phrase) and am left with a working drive with unaccessible data on it.

 

15 minutes ago, MAM59 said:

Sorry, I am out with that. I never understood why somebody wanted that. Its very unlikely that somebody can break into my computer room and steal a disk. Its much more likely that I forget the password (-phrase) and am left with a working drive with unaccessible data on it.

 

That's fair enough, everyone's situation and needs are slightly different