I am using V5RC3, no issues with the array.

 

I was copying some files using Midnight commander from a specific disk to a user share. I noticed the speed was incredibly fast, I checked and noticed that MC actually moved the files on the specific disk to another directory on the same drive, and it should not do that.

 

My setup:

 

One user share INCOMMING (only one assigned disk: disk5)

One user share SERIES (several assigned disks, but not disk5)

 

Copying from INCOMMING to SERIES results in the data remaining on disk5 but in the folder names corresponding with SERIES... Data is available thru user shares from windows but I was expecting the data to move from disk5 to one of the other drives..

 

What can be wrong ?  I used RENMOV in MC and was copying from /mnt/user/incomming to /mnt/user/series

If you go into the root level of disk5, does it show both shares?

The allocation settings are not used local moves. The system will keep files on the same disk but in the new user share. In order to move between disks use the disk# path names.

If you go into the root level of disk5, does it show both shares?

 

Yes, both shares are there.

The allocation settings are not used local moves. The system will keep files on the same disk but in the new user share. In order to move between disks use the disk# path names.

 

Just so I understand.. If I do the following from terminal:

 

mv /mnt/user/Incomming/filex.txt /mnt/user/Series/

 

then the files will just default to be copied to the disk that the original file was on ?  Even if the /mnt/user/Series share does not have that same drive allocated ?  I find that hard to believe.. Doesn't the unraid system decide where to move a file when it is copied to one of the virtual user shares ?

You essentially created the share when you gave it the command.

You essentially created the share when you gave it the command.

 

I am sorry but I do not understand that.. Can you try and explain to someone a little less linux knowledgeable ?

 

/mnt/user/<anything> is not a physical directory on the system but is pointed towards a virtual file system that unraid takes care of right ?

 

It is virtual share that is mounted within the linux system.

 

Why would I be able to copy to a user share from a windows station and have the file end up on any of the drives allocated to the share according to allocation rules but doing the same thing from within unraid does not work ?

 

Thanks for educating !

Just tested and the explenation given (that the directory is created by the mv and that this is default way of working) is not correct... I just copied a directory from /mnt/disk5/Incomming to /mnt/user/Movies and it behaved like I would expect it to...

 

It got moved to the cache drive and I expect it to be moved FROM the cache drive to a drive within the assigned drives after the mover runs..

Moving from user share to user share keeps the file on the same disk. Use disk shares to move files between disks. Allocation settings are only used for new writes to the array.

I bet the first time you did a move and the second time you did a copy.

 

My understanding is that this limitation in unRAID is there due to the slackware code unRAId is built on. If you move from one user share to another user share it will keep the files on the same disk and violate the user share settings. It will do this with a move both internally and a move via the network. Something to do with the code being coded to save time when moving files, since simply changing the directory tree on the same disk is much quicker than moving the file to another disk.

 

Do the move from the user share to the cache disk or do a copy and then delete the original files.

 

I bet the first time you did a move and the second time you did a copy.

 

My understanding is that this limitation in unRAID is there due to the slackware code unRAId is built on. If you move from one user share to another user share it will keep the files on the same disk and violate the user share settings. It will do this with a move both internally and a move via the network. Something to do with the code being coded to save time when moving files, since simply changing the directory tree on the same disk is much quicker than moving the file to another disk.

 

Do the move from the user share to the cache disk or do a copy and then delete the original files.

 

Moving to the cache drive works... Sounds like something that should work differently though... I would even call it a bug...

Or just use the disk shares.

 

You have already verified that you can successfully go from disk share to user share without this issue. I think it's only from user share to user share that it exhibits this behavior.