Storage Pool: Decouple storage pools from array

[Jaybau]

Proposing decoupling the array and pool maintenance operations, so both the array and pools can be maintained independently.

 

I don't want to stop the main array if I need to perform maintenance/changes to a pool.  This also causes outages for dockers, VM's.

Pools should be independent of the array.

Each pool should be independent from other pools.

Saved storage configurations may have potential improvements too.  Fortunately we can decide if a new configuration affects array and/or pool, but there can also be multiple unaffected pools.

Something similar to the functionality of Unassigned Drives; I want to manage independent pools like I can manage independent drives.

 

I assume the cache pool would be the exception since the cache pool is tightly integrated with the array. 

 

Might be worth considering redoing the UI to show the separation of the Array drives (parity+data+cache), and multi-drive pools, and unassigned drives.

 

Thank you for consideration.

[Bastian]

+1 from me, sounds like an awesome idea, though probably hard to implement with docker, samba and VMs running in the background 

[Jaybau]

4 hours ago, Bastian said:

+1 from me, sounds like an awesome idea, though probably hard to implement with docker, samba and VMs running in the background 

 

I'm asking for separating the multi-disk pools (non-array) from the main array. 

Docker containers and VMs run on the main array (e.g. cache).

Since containers and VMs don't run on multidisk pools (or unassigned drives), separating shouldn't be a problem.

 

Samba works for unassigned drives (via mount/unmount), so shouldn't be a problem for "unmounting" pools.

 

Basically, I'm asking multi-disk pools to behave more like unassigned drives.  Or the capability of pooling unassigned drives into a virtual filesystem.

 

 

[BVD]

12 hours ago, Jaybau said:

Proposing decoupling the array and pool maintenance operations, so both the array and pools can be maintained independently.

 

There's a huge amount of discussion around this, going back at least to 2015 - it was very nearly the one thing that kept me from purchasing in the first place actually 😳

 

I've also tried to articulate use-cases for this to justify the development effort as best I could.... I may also have... ranted... about it a bit 😅

 

Seems that the biggest thing keeping this from happening is UnRAID's licensing model - it's been noted that this would effectively require a complete re-write of the core/legacy OS components (array stop/start, device handling, service handling, etc). Understanding it's an utterly massive undertaking... I think it's absolutely a necessity at this point, as it's truly hampering the platform's flexibility more and more as time goes on 😓

 

Aaaanyway, please do upvote / comment on the feature request if you would - the more visibility we can get on it, the more people show the desire, the more likely it is to get the attention it needs to be scoped and implemented! 💚

 

EDIT: Looks like it goes back at least to ~2014, as a feature request by what was to become a Limetech employee 😅

Edited January 9 by BVD
Added earlier feature request reference

[itimpi]

It is already planned to make the current Unraid array just another pool type (of which you can then have multiples).  What the knock on implications around VMs and docker containers will be is not clear but it will presumably be decoupled from starting the main Unraid array (as you may no longer have one).

 

[JonathanM]

On 1/9/2024 at 12:56 AM, Jaybau said:

Since containers and VMs don't run on multidisk pools (or unassigned drives), separating shouldn't be a problem.

I don't understand this statement. My appdata and vm vdisks all live on a zfs 3 way SSD mirror currently.

[trurl]

On 1/9/2024 at 12:56 AM, Jaybau said:

Since containers and VMs don't run on multidisk pools (or unassigned drives), separating shouldn't be a problem.

I don't know what you mean here either. I expect most people run their containers on pools and not the array. I know I spend a lot of posts explaining how to get them off the array and why.

 

Way back before btrfs was introduced, many ran them on Unassigned, and probably some still do since it is allowed and the arguments in favor of changing something which is already working for them are not necessarily that compelling.

[trurl]

On 1/9/2024 at 12:56 AM, Jaybau said:

Docker containers and VMs run on the main array (e.g. cache).

You appear to have your own personal definition of 'array' that somehow includes the (possibly multidisk) pool named 'cache'.