Shares are not excluding disk

[whatabout]

disk18 is the only specified "Included" disk for a share called AppData (Plex library files, SAB/SB/CP installs and data directories). All other disks are specified as "Excluded" for this share.

 

disk18 is the only specified "Excluded" disk for all other shares, such as Downloads and Movies and TV. On these shares, the other disks (all but disk18) are specified as "Included".

 

The AppData share has no problem following these instructions, writing only to disk18.

 

And yet the other shares (Downloads and Movies and TV) are writing to disk18. They keep doing it.

[dgaschk]

What are the split level settings?

[whatabout]

What are the split level settings?

 

Downloads is set to 4.

(Example directory structure: DOWNLOADSSHARE>complete>movies>Files).

 

TV is set to 4.

(Example directory structure: TVSHARE>Continuing>ShowTitle>SeasonNumber>Files).

 

I set these up to 4 because ongoing series were crowding out individual disks.

 

Movies is set to 2.

(Directory structure: MOVIESSHARE>MovieTitle>Files).

[Joe L.]

I think it has been reported that include/exclude only prevents the creation of directories.  Once the directories exist, they will be used regardless of included/excluded settings.

 

 

Also, you should never populate both included and excluded for the same share.  only one is used (included I think) if it is populated.

[lionelhutz]

There was an issue with the way the user shares worked. If the file existed on a data disk in one user share and was moved to another user share it would stay on the same disk. From my understanding, it's a very low level part of SAMBA to make moves quicker since staying on the same disk means just the file table one the disk needs updating instead of writing the whole file onto another disk. Last time I saw this was back in the 4.6 days so I don't know if it still works this way.

 

On a different note, your TV and Movies split levels are set so high that no directories will stay together. For example, your MOVIESHARE set at 2 means that MovieTitle can exist on 2 different disks. Same applies with the TV, SeasonNumber can exist on multiple disks.

[dgaschk]

Using disk shares move the files from disk 18 to the cache drive. Delete the copies on disk18 and then run the mover. This may be faster using "mc" on the command line. If the cache drive is not big enough then copy the files directly to another data disk.

[whatabout]

Thanks, all.

 

I think it has been reported that include/exclude only prevents the creation of directories.  Once the directories exist, they will be used regardless of included/excluded settings.

That makes good sense. However I have moved the data off of disk18 and removed the directories, and they end up being created again.

 

Also, you should never populate both included and excluded for the same share.  only one is used (included I think) if it is populated.

Gotcha, thank you. I'm now using the "Included Disk(s)" field only.

 

There was an issue with the way the user shares worked. […]

Interesting. I haven’t encountered that before. Here, though, I’ve been moving the data off of the disk itself and the top-level folders for the shares are inevitably recreated.

 

On a different note, your TV and Movies split levels are set so high that no directories will stay together.

If SeasonNumber is on a disk which the TV share began using a long time ago - a disk which is nearly full - and the disk tops off before the end of the season, there’s nowhere for the season’s later episodes to go. When most disks are near capacity, I’ve come to be less particular about keeping entire seasons on a single disk. Perhaps I’m behaving insensibly?

 

Using disk shares move the files from disk 18 to the cache drive. Delete the copies on disk18 and then run the mover. This may be faster using "mc" on the command line. If the cache drive is not big enough then copy the files directly to another data disk.

That certainly gets the data off of the disk. But the issue is why it is being placed there to start, and how to keep it from continuing. I’ve got some stuff on cache now, waiting for the mover.

 

 

[dgaschk]

If the share doesn't exist on the drive (there should be no top level directory with the share name) and the drive is excluded (or not included) then the share should not be created on the disk. Examine the file /boot/config/shares/Movies.cfg and confirm that the include/exclude settings match the GUI settings.

[lionelhutz]

It sounds to me that You use disk18 for the download apps so the files start on that disk and when they get moved to their final destination you get the share directories created on disk18. Makes me think you have an issue with how the apps are setup.

 

Why are you using a data disk for those apps if you have a cache disk? Download to the cache, move to the share on the cache and then let the mover do it's thing.

[Riot]

This is the same issue I made an earlier thread about

 

http://lime-technology.com/forum/index.php?topic=29179.0

[dgaschk]

If the share doesn't exist on the drive (there should be no top level directory with the share name) and the drive is excluded (or not included) then the share should not be created on the disk during a new file write. Examine the file /boot/config/shares/Movies.cfg and confirm that the include/exclude settings match the GUI settings.

 

My amendment is in bold. The share settings only effect the creation of new files. Files existing in the array follow an entirely different rule.

[lionelhutz]

I did some testing and the files moved from share to share seem to properly go to the disk as dictated by the split level, allocation method and include/exclude settings.

 

Can you post a screen shot of the share settings? I've seen it where entering the disk list wrong causes it not to work.

 

[whatabout]

It sounds to me that You use disk18 for the download apps so the files start on that disk ...

 

Hmm. My first thought was, “No way! The download location is set right to the Downloads share, and disk18 is not included on that share.” But it got me questioning that assumption. And then I saw Riot’s link:

 

This is the same issue I made an earlier thread about

 

http://lime-technology.com/forum/index.php?topic=29179.0

 

and looked into that a bit more. As it turns out, the files _were_ being started on disk18. In SAB’s Folder settings, a leading / (slash) was missing in the “Temporary Download Folder” field. So the downloads were going into /mnt/user/AppData/sabnzbd-data/Downloads/downloading instead of /mnt/user/Downloads/downloading.

 

Since correcting the missing slash, the share directories have not been created on disk18. I’ve only had one incoming file to observe this with, but from what I can tell that seemed to have fixed the issue.

 

Is the array a proper location for incoming downloads, or should those all be going to the cache drive? After a few years of using unRAID and tweaking the way it (as well as the packages I run along with it) operates, I feel like things may be scattered more than they should. I wish there were a way to easily reorganize/redistribute existing data across the drives for best efficiency and capacity. But maybe that’s not as necessary as I think it is.