Given the new behavior of split level = 0, how do we achieve the old behavior (i.e. where a whole "Share" sticks to the same disk that it first gets created on (user level = -1 perhaps?) - I don't really want to have to specify the disk in the include/exclude lists, just whever it ends up I want the whole tree to stay together.

 

Lots of rambling for this question "what do I set the share level to in 4.3 to get what share level = 0 gave me before?"

 

Thanks

Doug

Given the new behavior of split level = 0, how do we achieve the old behavior (i.e. where a whole "Share" sticks to the same disk that it first gets created on (user level = -1 perhaps?) - I don't really want to have to specify the disk in the include/exclude lists, just whever it ends up I want the whole tree to stay together.

 

Lots of rambling for this question "what do I set the share level to in 4.3 to get what share level = 0 gave me before?"

 

Thanks

Doug

 

Yes, to emulate the old behavior you have to set the 'included disks' mask to the disk you want the share on.  I'll look at possibly using the value -1 for this.

 

The reason this was changed was that we get numerous support emails from people asking why their share runs out of space and doesn't use any of the other disks - of course the reason is that split level is set to 0, which is the default.  Then, if they don't care about keeping directories together, the answer is "set the split level high, like 999".

 

With the split-level value 0 change in this release, the default behavior is to have the system distribute files across all the disks, according to the allocation method, which is more intuitive and what one would expect with an array.

this is a very well thought change and I welcome it

 

as for -1 don't do it, why make things more complex when assigning a single disk in included disks is a much cleaner (and "intuitive") way

 

 

Can i suggest that this area of the documentation is given a serious going over ASAP.

 

It is not intuitive at all and the examples dont go far enough to make it clear cut. Add to this the change of settings in this version and its an area of user config that will baffle prospective buyers and potentially put them off.

 

Perhaps the community can do this for Tom on the wiki as a team effort and give him some time to look at the proposed plug in structure?

Just to jump back in on this having started the thread.  I agree that the new split level = 0 behavior is a better default behaviour.

 

However I really do not want to set the disk in the "include disk" list, this is really getting too far under the hood.  I know a lot of the guys who have been around since before user shares like that level of control - and that is cool.  But in my case, and I expect many others - I don't know or care which disks my data is on - I want unRaid to manage that for me.  The only thing I may care about is the grouping of that data which is what split level is all about.

 

So I may want to create a new share called "Music" - I dont care which disk it is created on (most free / high water cah decide) - but for spin up reasons I want everything that I put into that share to be on the same disk, this will clearly avoid spinup delays etc.

 

If -1 is too ugly then perhaps the -1 is under the hood and a check box "Keep all data for this share on one disk" or similar may be better - but please let us not lose that functionality - or ask users to know which disks their data ends up landing on.

 

...steps off soapbox...

 

p.s. don't get me wrong unRaid is a superb piece of software - I have recommended it far and wide.

Initially, I did not understand what you were trying to do, but with your last post I now understand better.  What you want to do is interesting, and valid, but not something unRAID was actually *designed* to do as yet.  You were using a design quirk of the Split Level feature, to basically assign a Share Label to a drive, something I don't think most of us had even thought of.  I have some comments...

 

I like and agree with your desire to leave the details of managing your data to the computer, but I think the choice of destination drives is one of the management decisions that might better be performed by the user.  Why?  Because of unRAID's ability to flexibly handle a mix-and-match assortment of drives, of differing sizes, brands, speeds, ages, and install times.  If I 'extrapolate' you to the abstract unRAID user, who may have a mix of small and large drives, that user might not want unRAID to decide to start his enormous collection of DVD's and TV recordings on an 80GB drive, or put his small photo collection on his terabyte drive.  I think it makes better management sense to specify the drive or drives for each collection, when you setup a User Share for it.  Photo collections, music collections, backups, and drive images can usually easily fit on small drives (60GB to 250GB).  Video collections generally need the largest drives you have.  And there can be other reasons why a user may want a specific collection on a specific type of drive.

 

Although this started as a quirk of the way 'Split Level = 0' worked, I think that adding a new Allocation Method might work better than a Split Level value of -1.  I would like to suggest it be called Ordered, as in an Ordered list of drives, where all new files are saved to the first drive in the Included Drives list.  If it fills up, then new files are saved to the next drive in the Included Drives list.  If there's only one drive listed, then (as Tom decides) it either returns a full disk error or another disk is assigned, one that is not Excluded.  If Included Disks is left empty, then it might work as you have asked, and let unRAID automatically pick a disk to start with, and add it to the Included Disks list.

 

Others may have a better term, but Ordered seems the most abstract way of describing a feature that could turn out to have other uses too.  It seems useful for any collection where you aren't interested in balanced disk use, but keeping a collection to as few drives as possible, letting it grow to new disks only as needed.

 

An advantage of this way of applying a User Share label to a drive, is that you can take advantage of the User Share advantages, such as the Cache drive, hidden physical drive names, additional security and access controls, and the ability to assign another drive to act as an automatic overflow drive, by including it in the Included Disks.  If you assigned a particular drive to a collection, and the collection outgrew the drive, it would automatically begin filling the second drive, and not return a full disk error, and fail the save of your file.  This feature is also more portable than directly using a specific physical drive, as you can easily move the /Music folder from one drive to another, adjust the Included Disks setup and reboot, and the Music Share will look exactly the same to external machines.  I know this all just sounds like the normal existing features of User Shares, but this really is a bit different, for managing single disk collections.  This lets me assign a second drive to a share, but know that it will not be used, unless I run out of room on the single disk I want this collection to be on.

I like ordered.