Mover not functioning properly

[jbartlett]

I have a 32GB SSD that I use to store files that are frequently accessed such as thumbnails and NFO files for movie/show details and use the platter drives to store the movie/TV media. This is so a platter drive doesn't have to spin up until a movie/TV episode is watched. This drive is configured as disk20, I have platter drives on disk1-disk10. A 500 GB cache drive is used.

 

When I invoke the mover, it's moving the large media files to disk20 even though I have the shared configured to exclude it and set to most-free - other drives have 400+ GB free. Even worse, it copied a file onto it that didn't fit and consumed 100% of the drive space. It then continued to try to copy the rest of the files onto disk20 even though it was full and reported failures and left zero byte files in it's wake. Fortunately, the source files on the cache drive were left as they were.

 

I just upgraded from b13 to RC5. The mover was functioning as desired previously and was copying the files onto disk10, the drive with the most free space.

 

Share details:

Allocation method: most-free

Min. Free space: 0

Split level: 2

Include disks:

Exclude disks: disk20

Use cache disk: Yes

 

Syslog attached - the log reports many files not found during the first mover run because I manually moved the thumbnails/nfo to disk20 after starting the mover and forgetting to move those files first - expecting that it would move them to one of the platter drives when I wanted it on the SSD. When I tested it again with a single file, it still moved it to disk20.

 

ETA:

It copied Season 1 to disk10 as expected since it had the most free space. Disk9 then became the drive with the most free space but the mover copied the "Season 2" directory onto disk20 instead.

 

When I "primed" disk9 by moving an episode from the "Season 2" directory onto it, the split-level logic kept the rest of the files on disk9. (Split level set up to keep the different seasons of a series on the same drive.)

syslog.zip

[dgaschk]

This is not an RC issue. The mover is functioning within the constraints of the share settings. Please post the directory structure of the share.

[PeterB]

You say that you moved thumbnails/nfo to disk20.  Did this mean that you created a "Season 2" directory on disk 20?  If so, then the system is doing what is required of it - moving any further "Season 2" files into the existing directory of that name, rather than creating a new directory (which would cause a split).

[jbartlett]

Hrm, you may be right. There was no "Season 1" directory when the mover started and it moved correctly. A "Season 2" directory existed on disk20 when it started to move the files for it. It looks like it scans for the first matching directory on the drives in sequence and then copies into that directory to maintain the split level - which explains why the other files were moved to disk9 after I created the directory there.

 

I had assumed that it would have excluded disk20 because the share was configured to exclude it.

 

But why did it still try copying a file onto disk20 when there wasn't enough room to hold it? (and thus create an incomplete file and zero-byte files)

 

Directory structure:

TV / Supernatural / Season x

[dgaschk]

The min free space setting is intended to prevent this behavior. Zero free space is specified and that is what it is attempting. Min free space should be set to at least the size of the largest file that you'll ever copy to the share. Twice the largest size is a safe setting. Min free space is specified in kilobytes.

[jbartlett]

So setting the shares to a min-free space of 33554432 which is equal to the size of disk20 (32GB) should ensure no files are ever copied there by the mover, even if I forget about the split level settings.

 

Gotcha.

[dgaschk]

Make it slightly larger than the current free space to be certain.

[lionelhutz]

So setting the shares to a min-free space of 33554432 which is equal to the size of disk20 (32GB) should ensure no files are ever copied there by the mover, even if I forget about the split level settings.

 

Gotcha.

 

I doubt it. I would expect the split level to over-ride the free space setting.

 

[jbartlett]

Hopefully the mover will still reject the file if the free space value is greater than the free space on the drive honoring the split level instead of copying a partial file. I'll have to experiment to test that.

[tyrindor]

So setting the shares to a min-free space of 33554432 which is equal to the size of disk20 (32GB) should ensure no files are ever copied there by the mover, even if I forget about the split level settings.

 

Gotcha.

 

I doubt it. I would expect the split level to over-ride the free space setting.

 

It will just leave the files on the cache drive if the split level wants it to go to X drive and the free space is below the free space setting. It won't send it to another drive, because that's what split level is designed to prevent.

 

OP, you are trying to complicate user shares into a way that was never intended. I get why you don't want to spin up the drives but you can't have a split level and then have the same directory on 2 different drives. Chances are you are just going to need to deal with spin ups, or disable spin ups and deal with the power usage. Cache_dir will get rid of most spinups, just don't go into folders with pictures unless you know you want to use something in there.

[jbartlett]

tyrindor:

 

Actually, it working pretty well even though I'm breaking up the split level. It seems the mover scans the drives in numeric sequence looking for the directory to honor the split and since the media is on disk9, it finds it before it finds the other directory on drive20 containing the thumbnails and places the large MKV files on disk9.

 

The share that combines all the directory listings still works and displays all files.

 

The issue I need to remember in this situation is to ensure the split level directory exists on a platter drive before invoking the mover if I had already moved the thumbnails to disk20.