[6.10.0-rc1] Share minimum free space not always being respected

Also changes to user share settings are not reflected, e.g. a user share is dedicated to disk2. If you then change it e.g. to a new cache pool only it still writes to disk2.

Fix Common Problems even produces a warning, that there is something wrong ... 

 

Please also refer to:

 

 

 

 

 

 

Furthermore:

 

When having one file on hdd_cache Pool (download user share on one single HDD) and trying to move this file to a different user share on the array, the file is not moved to the array. The file stays on hdd_cache Pool disk, but the directory of user share is created on hdd_cache Pool disk therefore!

 

The user share on the array has no cache option set (use cache pool is set to no).

I think this could also cause data loss if something then happens, e.g. with the single cache_pool disk!

 

I did a stop/start of the array => no change.

I did a reboot => no change.

 

It is also causing problems when setting up docker and afterwards trying to move, e.g. appdata folder to a cache disk.

 

1 hour ago, matty2k said:

The user share on the array has no cache option set (use cache pool is set to no).

Mover will only move to the array if use cache=yes for that share.

Of course. I know that. I did not say anything about the mover. I moved manually from one share to another with Krusader.

However, also the mover was not working at all for some other situations, where I have set up Cache=Yes. Files kept staying on the cache!

3 hours ago, matty2k said:

I moved manually from one share to another with Krusader.

You're bypassing the system when doing that.  Usually no problems, but if the use cache / include / exclude settings differ, then the file may wind up be in *apparent* violation of the rules you've set.

 

Basically the way everyone sets up Krusader is by having a single mount point of something like /UNRAID mapped to /mnt/user (or /mnt)  The way every OS works is that when moving files it first tries a rename.  Only if the rename fails then does a copy / delete operation take place.

 

In your case, Krusader tries to rename the file to the new share and it succeeds and the file stays put where it is.  

 

An identical situation happens via SMB and using "root" shares.  Normal moves via SMB and Unraid's shares will always honor the rules because the two shares you're moving between are different mount points, so the initial try Windows does at renaming fails so it has to physically move the file.

Dear Squid,

this is a very useful information which I did not have before. I only followed the tutorial by space invader to set up krusader and like he suggests it is quite comfortable to work with. But makes no sense for "organizing" (copy or move files/directories) your data.

 

However, I was using Krusader instead of SMB Shares on another Windows client because I have read somewhere, that SMB could be much slower in moving files than doing the operation directly on the server (since files need to go through the windows client while copying/moving).

 

But is there a possibility to organize the shares (erase, copy, move files and subfolders) directly on unraid avoiding the problems above? In Shares / User Shares I can only manage the parent directories, no file or folder movement possible or even delete files or (sub)folders.

 

kind regards

18 minutes ago, matty2k said:

However, I was using Krusader instead of SMB Shares on another Windows client because I have read somewhere, that SMB could be much slower in moving files than doing the operation directly on the server (since files need to go through the windows client while copying/moving).

Using Windows / SMB is actually awfully close to the speed of Krusader.  SMB / Windows is smart enough that if it knows that both the source and the destination are on the same server then all copies / moves happen directly on the server and no data goes through the network.  (ie: Depending upon your cache drives, hard drives etc you can quite easily exceed the maximum 110MB/s transfer rate when using a 1 Gig network.