jortan

I don't know what method people are using to try and have Unraid's own array system mount ZFS shares, but I don't believe that is supported. If you're happy to have an open share you can add something like this in /boot/config/smb-extra.conf [sharename] path = /mnt/poolname/dataset comment = share comment browseable = yes public = yes writeable = yes (edit: ZFS support is coming to Unraid soon and presumably this will include creating shares in the GUI for ZFS pools/datasets)

Depends on your risk profile. Your disk may fail soon, on the other hand I've had disks continue to operate for tens of thousands of hours with a handful of "reported uncorrect" errors.

Potentially bad memory:

I don't think it's indicative of a faulty pool, something is issuing a command to import (bring online and mount) all detected zfs pools. I think 1WayJonny's point is that there could be situations where a plugin randomly issuing a command to import all ZFS pools might not be desirable.

You can check this with: zpool history | grep import I have a several of these entries, but not since around 6 months ago, and this may have actually been me running the commands. I don't use these plugins, but I've just installed zfs-companion to see if that's causing these commands to be run.

The ZFS plugin isn't intended to replace the Unraid array (with it's flexibility to mix and match disks), but rather to replace the functionality otherwise provided by the cache drive/pool (ie. BTRFS) When ZFS is officially supported in Unraid (which has been hinted at), that will still be the case. edit: That said, ZFS raidz expansion is now a thing, and there has always been the option to fairly easily expand arrays with mirrored pairs (which is generally regarded as the best pool topology)

The Unraid "Shares" GUI is really designed for sharing Unraid array/pools. I would also recommend sharing a ZFS dataset using smb-extra.conf (or zfs set) rather than trying to do this in the Unraid Shares GUI. If you want a share that's open to anonymous (unauthenticated) access on your network: chown nobody:users /mnt/poolname/dataset chmod 777 /mnt/poolname/dataset In /boot/config/smb-extra.conf add a new share: [sharename] path = /mnt/poolname/dataset comment = this is a comment browseable = yes public = yes writeable = yes Restart samba service to load the new config /etc/rc.d/rc.samba restart sharename should now be visible at \\unraidhostname or \\unraid.ip.address

You can turn on closed captions, and then enable translation to english in the video settings - was pretty easy to follow: Thanks for this @UnRAID_ES

50Mbit/sec = ~6.5MB/sec <- typical 4K Bluray edit: it's typically a bit higher than this: https://en.wikipedia.org/wiki/Ultra_HD_Blu-ray Still, the array is probably not your issue with Plex + 4K

A high bitrate 4K file is likely to be around 5-10MB/sec, I doubt this was an issue with array performance. Plex has always struggled with 4K where transcoding is required. Worth another try, things may have improved.

Was plex on your Unraid array or cache pool? Can you describe what performance issues you were having? I'm not sure that nested virtualisation is the path to better performance!

The pool name isn't represented as a sub-folder of the mount location, it's mounted directly to the directory you specify. My suggestion would be not to overcomplicate this: zpool create -m /mnt/poolname poolname mirror sdb sdc zpool create -m /mnt/poolname2 poolname2 mirror sdd sde

Not only should you - you will need to. You can't mount multiple pools to the same path. It's probably fine. AFAIK the only reason not to mount zfs directly in /mnt/pool is this, which can just be ignored:

do you mean /mnt/disks/zfs/pool1 /mnt/disks/zfs/pool2 ? I believe /mnt/disks is where the unassigned disk plugin mounts disks? Probably not an issue, but to avoid any edge case issues I would just mount zfs pools here: /mnt/pool1 /mnt/pool2 For Samba sharing - you can either have ZFS do this - I haven't done it this way, but it's something like: zfs set sharesmb=on pool1 What I have done before is just add this to Unraid /boot/config/smb-extras.conf [sharename] path = /mnt/pool1 comment = share description browseable = yes public = yes writeable = yes vfs objects = This assumes you want the share to be public - accessible anonymously. If so, then: chmod 777 /mnt/pool1 chown nobody:users /mnt/pool1

+1 I have 4TB, 5TB, 8TB and 12TB disks, a combintation of 2.5" and 3.5", all in a single array. You can use disk slot inclusions/exclusions within your shares to ensure that performance-sensitive shares are only written to your fastest disks. (I also use ZFS disk mirrors for performance - ie. VMs)

How many drive bays do you have to achieve this? Enough for all your old and new disks at the same time? There's multiple options depending on your tolerance for maintaining parity - someone may want to chime in on the finer points: Option 1: - Replace your parity disks one-by-one - In Unraid "Shares" config, exclude all your old disks from your shares except the first disk slot you are about to replace. (The shares will still show any files present on the old disks, but this will prevent new files being written to them.) - Replace your disks one-by-one - unexclude the disk slots from your shares when they have been replaced with a 16TB disk. - As you replace the disks with larger ones, use "unBALANCE" plugin to merge data from multiple smaller disks to the new disks. - When you've finished, your array should have 2 x 16TB parity disks, all your data on 16TB disks, and a bunch of empty 6TB disks. - Take a screenshot of your current array and slot assignments (noting which 16TB disks are parity and which are data) - Move any files on cache pool if used (Settings | Scheduler | Move Now) - Use "Tools | New config" to reconfigure the array to only include the new 16TB parity/data disks. You should be able to "copy" your current disk assignments, and then just remove the 6TB disks before accepting the new array configuration. Read and understand the warnings presented at this point (you shouldn't need to format any disks). If you lose the array config for some reason, refer to screenshot and create an array with 16TB parity/data disks in their correct slots. Note that you will need to regenerate parity at this point, so you will have a day or so without parity protection If you have enough drive bays you can even do something similar to above, except a bit easier: - Replace your parity disks one-by-one - Then add *all* the new disks to the current array - Exclude all your old disks from your shares - Move the data from old disks to new disks using unBALANCE - "Tools | New config" to re-configure the array to only include the new disks/parity drives. Option 2: Unraid isn't RAID5 - file data isn't sliced and distributed among disks - Unraid arrays are just a bunch of xfs formatted disks (optionally with parity). You can just copy or move everything from your current array to the new disks formatted as XFS. Once you have copied or moved all your data to the new disks, use "Tools | New config" to "create" a new array that includes only your new data disks and those you want to assign to parity. This will take a long time, so may be hard to manage if you need to keep the array "live" for new writes.

Borgbackup provide a binary that seems to work https://github.com/borgbackup/borg/releases wget https://github.com/borgbackup/borg/releases/download/1.2.2/borg-linux64 /boot/config/borg-linux64 Run these and also add them to /boot/config/go cp /boot/config/borg-linux64 /usr/local/sbin/borg chmod +x /usr/local/sbin/borg Alternative you could use something like the borgmatic docker, mount whatever paths you need borg to have access to, and run your commands from the docker's console or using "docker exec"

Here's another post with information more specifically about setting boot order for passthrough nvme:

/mnt/user is where unraid does it's magic for shares backed by Unraid arrays / cache devices. My advice would be to leave /mnt/user alone and not attempt to manually mount (or link) filesystems here. Maybe I'm missing something but can you not go to: - Settings - VM Manager And set "Default ISO storage path" to /zfs-sas/isos ? Fairly sure this is what most Unraid/ZFS users are doing.

Can confirm the current "next" build of 6.10.2-rc3 is also working if you wanted to try that. VVV oops, you're right - thanks

The other thing you can do is zfs set sync=disabled poolname This forces all writes to be asynchronous. This doesn't risk data corruption, but it does risk the last 5 seconds of your data in the case of a power failure which could lead to data loss in some scenarios. If you happen to be moving data to the array at the time - The sender has been told the data is moved so the source is deleted, but it won't actually get written to the destination for 0-5 seconds. You could see significant performance benefit on a busy pool though - particularly one seeing lots of small synchronous writes.

This seems about what I would expect. You're not streaming data directly and uninterrupted to your spinning rust as you would be in a RAID0-like configuration. For every write to one disk, ZFS is having to store that data and metadata redundantly on another disk. Then the first disk gets interrupted because it needs to write data/metadata to provide redundancy for another disk. You're not streaming data neatly in a row, there are seek times involved. If you want performance with spinning rust, get more spindles and ideally switch to RAID10 (mirrrored pairs)

To clarify, it's relevant for any application doing synchronous writes to your ZFS pool. For these writes, the file system won't confirm to the application that the write has been completed until the data is confirmed as written to the pool. Because writes to SLOG are much faster, there can be significant improvements in write performance. SLOG is not a read cache - ZFS will never read from the SLOG except in very rare circumstances (mostly after a power failure.) Even if it could, it would be useless as the SLOG is regularly flushed and any data is already in memory (ARC) If your application is doing asynchronous writes, ZFS stores the write in memory (ARC) and reports reports to the application that the write was complete (it then flushes those writes from ARC to your pool - by default every 5 seconds I think?) The SLOG has zero benefit here. I have a feeling QEMU/VMs will do synchronous writes also, but I don't have an SLOG running to test. From memory NFS shares default to synchronous and SMB shares will default to asynchronous? >>Intel Optane P1600X 118GB That said if you have/are getting this for L2ARC anyway, you may as well slice off 10GB for a SLOG. I was running a P4800X in exactly the same way a while ago.

Yes for HDD pools zstd makes more sense as you are IO bound by slow spinning rust. Needing to read and write less data to spinning rust is more likely to be beneficial than any increase in computation required for compression/decompression. For NVME you are less bound by IO, so the increase in computation required by zstd is more likely to impact performance negatively. On modern computers it probably makes very little difference. If you're rocking 10-year-old Xeons (like me) then it might. That said, zstd also gives better compression (to varying degrees, depending on the type of data) so if that's important to you it's another thing to consider.

For NVME you're probably better of using lz4 by default, and zstd for datasets with very compressible data (large log/text files), or for datasets you don't read often (archives/backups.) Some insights here: https://news.ycombinator.com/item?id=23210491