Here is an interesting defect!

 

unRAID OS Version:

v6.0.1

 

Description:

Misleading error message when mover runs.

 

How to reproduce:

Create a share (in my case one called Films) with:

- Split Level set to Manual

- Include disks to limit the disks to be used by the share

- Set the share to use the cache

- make sure the Films folder exists on all included disks.

 

Create a folder on another disk (e.g. Films/Z) that is NOT part of the above share but with the folder name corresponding to the share.

 

Copy a file over the network to the user share Films/Z.  This will actually end up being written to cache/Films/Z/filename  and will be visible under Films/Z/filename  (which is correct)

 

Start up Mover.  It will try and move the file that is in cache/Films/Z to /mnt/user0/Films/Z and will fail with an error message about the being no space on the device.

 

Expected results:

 

Not quite sure what whould happen here. 

Either

  the folder Films/Z should be created on one of the disks that is part of the share (which feels like the correct behaviour)

  Or

  if mover still wants to create the file on a disk that is not part of the array the error message should be more meaningful

 

Actual results:

 

Mover fails and give an error message indicating that the move has failed due to the being no space on the device  when trying to move the file to user0/Films/Z/filename

 

 

Other information:

 

This actually happened when I was doing some reorganising of the disks on my server so did a New Config and assigned the drives to different disk slots.  It took me some time to realise what had gone wrong.

 

If I change the share settings so that Use Cache is set to No, then I get an immediate failure about not enough space.  It appears that at one level unRAID is realizing the drive with the folder on is not part of the array, while at another is still selecting that drive as a target for the file.

 

I have not done any testing to see if a Split Level other than manual will work.

 

 

I would never expect the following to happen because you have split level set to MANUAL, which I believe instructs unRAID to never ever create top level directories.

 

the folder Films/Z should be created on one of the disks that is part of the share (which feels like the correct behaviour)

 

The error message makes sense once you think about what it's trying to do. It's trying to copy the directory/file to a pool of drives (as configured in your include disk) but NONE of them have any space allocated to it (ie: none of them have a top level directory called Films), so it sees it as no space available.

 

I would never expect the following to happen because you have split level set to MANUAL, which I believe instructs unRAID to never ever create top level directories.

 

the folder Films/Z should be created on one of the disks that is part of the share (which feels like the correct behaviour)

 

The error message makes sense once you think about what it's trying to do. It's trying to copy the directory/file to a pool of drives (as configured in your include disk) but NONE of them have any space allocated to it (ie: none of them have a top level directory called Films), so it sees it as no space available.

all the disks in the share have a top level folder of Films.  What they do not have is a sub-folder of Z.    In Manual mode that would normally mean that one of the disks in the share would be selected to hold the folder Z, and that is the behaviour if no other disks in the system have a top level folder of Films/Z.    However unRAID seems to be getting confused when another disk on the system that has the Films/Z folder.  As I understand it nRAiD should never be trying to create files on a disk which is not in the Includes list.

I would never expect the following to happen because you have split level set to MANUAL, which I believe instructs unRAID to never ever create top level directories.

 

the folder Films/Z should be created on one of the disks that is part of the share (which feels like the correct behaviour)

 

The error message makes sense once you think about what it's trying to do. It's trying to copy the directory/file to a pool of drives (as configured in your include disk) but NONE of them have any space allocated to it (ie: none of them have a top level directory called Films), so it sees it as no space available.

all the disks in the share have a top level folder of Films.  What they do not have is a sub-folder of Z.    In Manual mode that would normally mean that one of the disks in the share would be selected to hold the folder Z, and that is the behaviour if no other disks in the system have a top level folder of Films/Z.    However unRAID seems to be getting confused when another disk on the system that has the Films/Z folder.  As I understand it nRAiD should never be trying to create files on a disk which is not in the Includes list.

 

It wasnt clear from your report that included disks have the Films toplevel directory already created.

 

Two different behaviors to check out from your scenario:

So if you remove the directory Films/Z from the excluded disk, does mover work then?

So if you create a directory Films/Z on an included disk, does it work then?

 

I always thought manual mode meant not to create of any top level directories so you the user has to create them all. Its never been that clear to me, so I never use manual setting.

Okay, thanks for explaining that.

 

Now i can see wanting to have a better error message.

 

What i think would be really useful is a "whatif" mode on mover, split levels, and shares (include, exclude, min free space). It would generate a verbose information on what is being examined and why certain decisions are being made. I think that would be very useful as it seems there are many nuances that come into play. Its been a while now and most threads seem to be about docker or vm setups, but in the past there was always a constant flow of threads asking about mover/split level/include/exclude/min free.

 

I dont think anyone has taken a swing at this because the logic is all burried in closed source user filesystem shfs with no api into it (other than live filesystem calls), and its nuanced enough to be difficult in reproducing.

 

Sorry to hijack a bit, but this issue just reminded me of all the other user experience issues in this related area that needs to be improved.

I would never expect the following to happen because you have split level set to MANUAL, which I believe instructs unRAID to never ever create top level directories.

 

the folder Films/Z should be created on one of the disks that is part of the share (which feels like the correct behaviour)

 

The error message makes sense once you think about what it's trying to do. It's trying to copy the directory/file to a pool of drives (as configured in your include disk) but NONE of them have any space allocated to it (ie: none of them have a top level directory called Films), so it sees it as no space available.

all the disks in the share have a top level folder of Films.  What they do not have is a sub-folder of Z.    In Manual mode that would normally mean that one of the disks in the share would be selected to hold the folder Z, and that is the behaviour if no other disks in the system have a top level folder of Films/Z.    However unRAID seems to be getting confused when another disk on the system that has the Films/Z folder.  As I understand it nRAiD should never be trying to create files on a disk which is not in the Includes list.

 

It wasnt clear from your report that included disks have the Films toplevel directory already created.

 

Two different behaviors to check out from your scenario:

So if you remove the directory Films/Z from the excluded disk, does mover work then?

Yes.  The Z folder gets created on one of the disks that is included in the share (based on allocation method to pick the disk).

So if you create a directory Films/Z on an included disk, does it work then?

If the folder is not also on the excluded disk then this is the same as the case above, except here I control which disk the Z folder is created on.

 

If the folder exists on both an included and an excluded disk then whether it works or fails depends on which disk would be chosen based on allocation method (i.e. it can sometimes work and sometimes not work).

 

Also bear in mind that I originally raised the error as being about a misleading error message.  The error when it occurs is not about lack of space as reported, but about having permission to create the folder/file on the disk chosen by unRAID as the target.

 

I therefore think there are two possible defects here.  One is a small one about the error message on failure not indicating the real reason, and the other about the algorithm unRAID is using to select the target disk for file creation.

 

The suggestion about having more logged information about which disk is selected in such a case would help with diagnosing such issues.  However it may not be that easy to do this without flooding the log in normal operation - it is only when things go wrong one that one is really interested in this type of information in the log.  A better error message simply saying that the file could not be created because of share settings would be more that enough and point one towards the actions required to fix the issue.