Raid Z2 help

Submitted ⁨⁨5⁩ ⁨days⁩ ago⁩ by ⁨a_fancy_kiwi@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

tldr: I’m going to set up raid z2 with 4x8TB hard drives. I’ll have photos, documents (text, pdf, etc.), movies/tv shows, and music on the pool. Are the below commands good enough? Anything extra you think I should add?

sudo zpool create mypool raidz2 -o ashift=12 /dev/disk/by-id/12345 ...

zfs set compression=lz4 mypool #maybe zstd?
zpool set autoexpand=on mypool
zpool set autoreplace=on mypool
zpool set listsnapshots=on mypool

With ai raising hard drive prices, I over spent on 3x10TB drives in order to reorganize my current pool and have 3 hard drives sitting on a shelf in the event of a failure. My current pool was built over time but it currently consists of 4x8TB drives. They are a mirrored stripe so a usable 16TB. If I understand it correctly, I can lose 1 drive for sure without losing data and maybe a second drive depending on which drive fails. Because of that, I want to move to raid z2 to ensure I can lose 2 drives without data loss. I’m going to move data from my 4x8TB drives, to the 3x10TB, reconfigure the 4x8TB, and move everything back. I run Immich, plex/jellyfin, and navidrome off the pool. All other documents are basically there for storage just in case. What options should I use for raid z2 when setting it up?

source

Comments

Sort:hotnew top

avidamoeba@lemmy.ca ⁨5⁩ ⁨days⁩ ago
I do:

sudo zpool create \ -o ashift=12 -O acltype=posixacl -O compression=lz4 \ -O dnodesize=auto -O normalization=formD -O relatime=on \ -O xattr=sa \ mypool \ raidz2 \ wwn-0x5000cca284c06395 \ wwn-0x5000cca295e115f3 \ wwn-0x5000cca2a1ef9c90 \ wwn-0x5000cca295c03910 \ wwn-0x5000cca29dd216b0

I’m then going to optimize recordsize depending on the workload in datasets. E.g. Immich db might use 8K or 16K recordsize while the library dataset where the files are might be larger so that search is faster. Etc.
source
- a_fancy_kiwi@lemmy.world ⁨5⁩ ⁨days⁩ ago
  Thank you for this
  
  source
  - avidamoeba@lemmy.ca ⁨5⁩ ⁨days⁩ ago
    The acl, norm, xattr options are all to make ZFS behave like a Linux filesystem.
    
    source
greyfox@lemmy.world ⁨3⁩ ⁨days⁩ ago
You probably shouldn’t enable compression on the root filesystem of the pool. Since you mention movies/TV shows/music those are just going to waste cpu cycles compressing uncompressable data.

Instead you should consider separate ZFS filesystems for each data type. Since ZFS is a pool you don’t have to pre-allocate space like partitions so there is no harm in having separate filesystems for each data type rather than single large filesystem for everything. You can then turn on compression only for those filesystems that benefit from it.

Also remember that many permissions like nfs export settings are done on a per filesystem basis so you should lay out your filesystems according to your data type and according to what permissions you want to give out for that filesystem.

i.e. if you are going to have a Navidrome server to stream your music you don’t want to give that server access to your entire pool, just your music.

Separate filesystems also means you can have different snapshot schedules/retentions. Documents might need to snapshot more often, and be kept around longer than media snapshots.

source
- BlackAura@lemmy.world ⁨3⁩ ⁨days⁩ ago
  If I recall correctly compression, especially lz4, has been shown to impact performance negligably.
  
  source
  - greyfox@lemmy.world ⁨3⁩ ⁨days⁩ ago
    Yeah it won’t make much difference these days.
    
    I suppose my point was more so that because ZFS is a pool that can be split up with filesystems new users should be thinking a little differently than they would have been used to with traditional raid volumes/partitions.
    
    With a normal filesystem partitions are extremely limiting, requiring you to know how much space you need for each partition. ZFS filesystems just being part of the pool means that you can get logical separation between data types without needing that kind of pre-planning.
    
    So many settings with ZFS that you may want to set differently between data types. Compression, export settings, snapshot schedules, replicating particular data sets to other systems, quotas, etc.
    
    So I was mostly just saying “you should consider splitting those up so that you can adjust settings per filesystem that make sense”.
    
    There is also a bit of danger with a single ZFS filesystems if you have no snapshots. ZFS being a copy on write filesystem means that even deleting something actually needs space. A bit counter intuitive but deleting something means writing a new block first then updating the FS to point at the new block. If you fill the pool to 100% you can’t delete anything to free up space. Your only option is to delete a snapshot or delete entire filesystems to free up a single block so that you can cleanup. If you don’t have a snapshot to delete you have to delete the entire filesystem and if you only have one filesystem you need to backup+delete everything… ask me how I know this ;)
    
    If you have several filesystems you only need to backup and destroy the smallest one to get things moving again. Or better yet have some snapshots you can roll off to free up space or have quotas in place so that you don’t fill the pool entirely.
    
    source
- non_burglar@lemmy.world ⁨3⁩ ⁨days⁩ ago
  With respect, most of this comment is wrong.
  
  Both lz4 and zstd have almost no performance impact on modern hardware.
  
  compression acts on blocks in ZFS, therefore it is enabled at the pool level
  
  ZFS does indeed need to allocate some space at the front and end of a pool for slop, metaslab, and metadata. I think you are confusing filesystem and datasets.
  
  Also remember that many permissions like nfs export settings are done on a per filesystem basis
  
  I’m not sure what you’re trying to say about NFS and ZFS, here but this is completely false, even if you mean datasets.
  
  source
  - greyfox@lemmy.world ⁨3⁩ ⁨days⁩ ago
    Well I am not claiming to be a ZFS expert, I have been using it since 2008ish both personally and professionally.
    
    Both lz4 and zstd have almost no performance impact on modern hardware. So “almost” is zero in your mind? Why waste the CPU cycles on compressing data that is already compressed? I recognize that you might not care, but I sure do. And I wouldn’t say it would be wrong to think that way.
    
    compression acts on blocks in ZFS, therefore it is enabled at the pool level
    
    This is incorrect. You can zfs set compression=lz4 dataset (or off) on a per dataset basis. You can see your compression efficiency per dataset by running zfs get compressratio dataset, if your blocks were written to a dataset with compress=off you will see no compression for that dataset. You can absolutely mix compressed and uncompressed datasets in the same pool.
    
    OP added a -O option to set compression when he created the pool but that is not a pool level setting. If you look at the documentation for zpool-create you will see that -O are just properties passed to the root dataset verses -o options which are actual pool level parameters.
    
    You might be confusing compression and deduplication. Deduplication is more pool wide.
    
    ZFS does indeed need to allocate some space at the front and end of a pool for slop, metaslab, and metadata. I think you are confusing filesystem and datasets.
    
    Well yes and no here. You are right I should have been calling them datasets. Datasets are a generic term, and there are different dataset types, like file systems, volumes and snapshots.
    
    So yeah I maybe should have been more generic and called them datasets but unless OP is using block volumes we are probably talking about ZFS file systems here. Go to say the zfsprops man page and you will see file system mentioned about 60 times when discussing properties that can be set for file type datasets.
    
    I’m not sure what you’re trying to say about NFS and ZFS, here but this is completely false, even if you mean datasets.
    
    It sounds like you are unaware of the native NFS/SMB integrations that ZFS has.
    
    It is totally optional but instead of using your normal /etc/exports to set NFS settings ZFS can dynamically load export settings when your dataset is mounted.
    
    This is done with the sharenfs parameter zfs set sharenfs=<export options> dataset. Doing this means you keep your export settings with your pool instead of the system it is mounted on, that way if you say replicate your pool to another system those export settings automatically come with it.
    
    There are also sharesmb options for samba.
    
    My point was then that you should lay out your dataset hierarchy based on your expected permissions for NFS/SMB. You could handle these exports manually yourself and not have to worry about it.
    
    My comment was less about compression and more about saying that you should consider splitting your datasets based on what is in them because the more separate they are the more control you have. You gain a lot of control, and lose very little since it all comes from the same pool.
    
    Some of the reasons I have that options is less important than it was a decade ago. i.e. doing a 20tb ZFS send before resuming a send was possible sucked. Any little problem and you have to start over. Having more filesystems meant more smaller sends. And yeah I was using ZFS before lz4 was even an option and CPU was more precious back then, but I don’t see any reason to waste CPU cycles when you can create a separate file system for your media and set compression to off on it.
    
    source
    -> View More Comments
- a_fancy_kiwi@lemmy.world ⁨3⁩ ⁨days⁩ ago
  Let’s say I did turn on compression on root. I can’t then turn it off on a per file system basis where it isn’t needed?
  
  source
  - greyfox@lemmy.world ⁨3⁩ ⁨days⁩ ago
    Yep you can certainly do it that way.
    
    If your concern is just that you already created it you can shut it off after the fact. All new blocks written will have compression disabled.
    
    source
    -> View More Comments
tvcvt@lemmy.ml ⁨5⁩ ⁨days⁩ ago
I’m sure you already know this, but do note that with Z2 compared to mirrors, you should expect a decrease in performance and an increase in rebuild times in the event of a drive failure. Not saying don’t do it, but make sure the perceived benefits are worth the trade offs.

Here’s some more info on the topic: jrs-s.net/…/zfs-you-should-use-mirror-vdevs-not-r….

source
- a_fancy_kiwi@lemmy.world ⁨5⁩ ⁨days⁩ ago
  Yeah I’m not excited about the write and rebuild times being slower but the read times should still be pretty good. Considering I don’t have any more space for drives in my server and I don’t know how crazy hdd drive prices will get in the next 12 months, the guaranteed 2 drive failure resiliency is more important to me at the moment.
  
  source
  - eleitl@lemmy.zip ⁨3⁩ ⁨days⁩ ago
    Make sure you scrub weekly. The probability of a second device failure is higher than you think, since it can be triggered by resilvering. I would also make sure you have a spare at hand.
    
    source
- non_burglar@lemmy.world ⁨5⁩ ⁨days⁩ ago
  That’s still true, but performance has changed a lot since Jim Salter wrote that. There was a time When 2x mirrored vdevs (the equivalent to raid 10) would have been preferable to raidz2, but performance of both ZFS and disks themselves has improved enough that there wouldn’t be much of a difference in performance between these two in a home lab.
  
  Personally, I agree with you in that mirrors are preferable, mostly because I don’t really need high availability as much as I want an easier time restoring if a disk fails.
  
  source

Decronym@lemmy.decronym.xyz ⁨3⁩ ⁨days⁩ ago

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters	More Letters
NFS	Network File System, a Unix-based file-sharing protocol known for performance and efficiency
SMB	Server Message Block protocol for file and printer sharing; Windows-native
ZFS	Solaris/Linux filesystem focusing on data integrity

[Thread #118 for this comm, first seen 26th Feb 2026, 06:01] [FAQ] [Full list] [Contact] [Source code]

source