Feature Request Poll for 6.11


What do you want to see in Unraid OS 6.11?  

732 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

On 8/26/2021 at 7:48 PM, Agent Crimson said:

I am a reletively new unRaid user with a small server. Originally unRaid was a hard sell on me for the sole reason it didn't have zfs. I love how user friendly it is and applications like Nextcloud and Plex were simply a few clicks. I am also a heavy Proxmox user and due to the how unRaid's parity works I got fed up and was about to leave unRaid. If ZFS is added it would be the best thing I would hands down become a unRaid power user too. There are a lot of things I just prefer about Proxmox which is not a discussion for here but I definitely won't be biased and will be running a hybrid setup thanks to zfs

unraids parity works, for the most part, like any other parity system.

 

you can just use freenas if you want zfs :)

Link to comment
3 hours ago, JasonK said:

unraids parity works, for the most part, like any other parity system.

 

you can just use freenas if you want zfs :)

Most part, parity is the same. But the big difference is that ou explain, you can read data off remainig drives, event if all parity + 1 drives failed. It's at the cost of writes performance when Turbo Write is OFF, but this ability (to read the others drives) is so great.

 

And there are multiple options to do ZFS in Unraid, FreeNAS/TrueNAS in a VM is an option. The ZFS plugin is another for example.

 

That's why I prefer multiple arrays instead of ZFS

Edited by dada051
  • Like 2
Link to comment
On 8/7/2021 at 4:54 PM, jonp said:

The reason it isn't on this list for this poll is for reasons that might not be so obvious. As it stands today, there are really 3 ways to do snapshots on Unraid today (maybe more ;-). One is using btrfs snapshots at the filesystem layer. Another is using simple reflink copies which still relies upon btrfs. Another still is using the tools built into QEMU to do this. Each method has pros and cons. 

 

The qemu method is universal as it works on every filesystem we support because it isn't filesystem dependent. Unfortunately it also performs incredibly slow.

 

Btrfs snapshots are really great, but you have to first define subvolumes to use them. It also relies on the fact that the underlying storage is formatted with btrfs. 

 

Reflink copies are really easy because they are essentially a smart copy command (just add --reflink to the end of any cp command). Still requires the source/destination to be on btrfs, but it's super fast, storage efficient, and doesn't even require you to have subvolumes defined to make use of it.

 

And with the potential for ZFS, we have yet another option as it too supports snapshots!

 

There are other challenges with snapshots as well, so it's a tougher nut to crack than some other features. Doesn't mean it's not on the roadmap ;-)

I would personally ignore QEMU snapshots and just support snapshots in general with btrfs and ZFS, if ZFS is planned to be officially supported. (Performance warnings should be provided for those who snapshot VMs however on btrfs, since we use NOCOW to specifically avoid this. Snapshotting a nocow file requires copy on write to actually work which can negate the use of the NOCOW attribute.)
 

Snapshots are a core feature of both filesystems after all and work rather well, so it would be great to take advantage of them in a way that is convenient for the user. The UI could be updated to just create subvolumes when creating user shares, and there could even be a way to migrate old directories based shares to subvolumes on supported filesystems. Adding an ability to schedule snapshots and rotate them would also be nice, and it has the added benefit of being able to help protect against ransomware attacks on your SMB share.


Now obviously there are a few caveats to this, but let me quantify, here's how I would approach this:

I'd start with support for the "multiple arrays", but much better and configurable than it currently is. Btrfs (and ZFS) RAID could then become first class citizens for users who choose to use either of those instead of regular unraid parity. This is when snapshots could be easily supported as they would be an array specific feature. I wouldn't really focus on its support on cache pools or with regular unraid parity, since it's convoluted to pull off (you'd have to snapshot each independent disk, and if you have any mixed filesystem setups, it wouldn't be possible).

 

Having this expanded "multiple arrays" functionality would thus need to be done before proceeding with full ZFS support.

 

Both Btrfs and ZFS support self healing with scrub, but in the current state of the array you can't utilize it if you go with btrfs (apart from metadata with get duped). Your only option is to use a cache pool (or potentially unassigned devices), which aren't really great for general data storage, because then you can't really use the "cache pool" as a write cache anymore as it was intended, since it's acting as your array. This is actually how I use unraid right now btw. I simply assign a USB drive to the array just so I can start it and totally ignore its functionality, relying on btrfs RAID1 for my HDD array (don't need the extra space parity provides me and this protects my data much better than any parity raid could apart from ZFS RAIDZ).

 

With "multiple arrays", you'd get to choose Unraid Parity (the default), Btrfs, or potentially ZFS. The UX/UI design for Btrfs could easily be reused for ZFS when it's added, apart from the flexibility to add and remove devices, and you'd still be able to easily use cache pools for faster SSD writes while still being able to have the hard disk array be self healing. It would also allow users of ZFS or Btrfs arrays to easily use SSDs and TRIM in an array, which isn't really possible now without major downsides.


For snapshotting VMs themselves, this is the only thing I'd use reflink copies for, and it could be supported on cache pools. I wouldn't use them for anything more as you potentially suggested, as to "snapshot" an entire volume (ie, on xfs, since it also supports relinks) using that method would not only be slow, but also use *a lot* of metadata if you have a lot of files, since it's really allocating all those inodes all over again. A real snapshot is basically a glorified "i owe you", deferred reflinks, and best suited to a single btrfs or ZFS array where it's easy to manage.

 

Would really love to see this! Whatever you folks do, I'm sure I'll be excited to see it. Running the 6.10 RC right now :)

  • Like 1
Link to comment

I voted for multiple arrays. 

 

For a home user like me the flexibility of adding a single disk at a time, the savings in both "wear and tear" on disks and energy by only spinning up single drive at a time, is primary reason I purchased UNRAID in the first place. I consider this feature the "bread and butter" for UNRAID and I really hope it will be expanded upon very soon. 

 

zfs is not really important to me right now. It is build with enterprise in mind and I don't really need most of the features and especially not the hassle about not being able to add drives etc. 

 

I have no idea what I would be using QEMU-ARM for. I consider this a niche feature. 

Edited by RecycledBits
Link to comment

I voted for multiple arrays also.  I use Unraid for the most part as a PLEX server - the drives spend most of their time in read mode.  Because of this, I purposely populated the array with WD SMR drives since they perform well in read mode.  From what I've read SMR and ZFS is not a good match due to the more frequent writes that ZFS does compared to XFS.  If Unraid moves to ZFS in 6.11 then I'd have to fork out $$$ to replace my SMR drives.  Just my $0.02.

Edited by bwnautilus
Link to comment

I know this isn’t one of the poll options, but I would LOVE to see enhancements to the docker interface. A gui able to use docker-compose and stacks. Similar to portainer but not exactly. A lot of things you find online all use compose and having that option in the gui I think would only make the user experience that much better. 

Link to comment
12 minutes ago, neruve said:

I know this isn’t one of the poll options, but I would LOVE to see enhancements to the docker interface. A gui able to use docker-compose and stacks. Similar to portainer but not exactly. A lot of things you find online all use compose and having that option in the gui I think would only make the user experience that much better. 

Actually, now that I think about it, this could probably be made as a plug-in. Something like paste in a docker compose, and it could just convert them to Unraid templates, like a little wizard, paste in, click next, shows the first service template, click next, shows the second, etc, etc, click done at the end and wham pulls the containers. 
 

may be even easier to show all services on the same template screen just separated. That way you can see it all in the same place. Actually, that would allow you to create stacks with the standard system. Like multiple container templates on the same screen with an apply at the bottom. 

Edited by neruve
Link to comment