Shares using Cache even when set to No.


ibbanez

Recommended Posts

I have the setting Use Cache: No set on most of my shares, except some like Bittorrent, downloads, etc.  However, I noticed that the 2x1TB cache drives that I setup in Raid 0, was getting close to full.  So I went in the drive and took a look, and it had a whole bunch of Shares that I specifically turned cache off in them.  Also, when invoking Mover, it never comes close to moving everything.  Like this time, it moved maybe 200 GB, but left the rest.  What is going on, and how do I fix this?  Thanks.

Link to comment

User Share settings only affect what happens with new files. And Mover only moves cache-yes shares from cache to array, or cache-prefer shares from array to cache. Mover never moves cache-no or cache-only shares.

 

So, to get files moved from cache, you must set the user share to cache-yes and run mover. Then if you don't want any more files written to cache you would set the user share to cache-no.

 

There is Help in the webUI for most things. You can toggle Help on/off for the entire webUI with the Help (?) on the top bar. Or you can toggle help on/off for a specific setting by clicking on its label.

 

See this FAQ for more details about how these settings work:

 

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-537383

 

  • Like 1
Link to comment
1 hour ago, ibbanez said:

I just don't understand if Use Cache is set to No, shouldn't the files never go to the cache drive then?  I did mover, for moving the files from my Downloads, etc. 

Setting a user share to cache-no will not do anything with files that are already on cache. Mover won't move them as I said.

 

Did you study the FAQ I linked?

Link to comment

Yes its intentional.  None of them are inside another.  I understand that Mover wont move them as their folder is set to No.  What I want to know is how they ended up there to begin with.  Those files weren't there before.  The only folders that I have Cache turned on, is Bittorrent Downloads, JDownloader, and Newsgroup Downloads, the others are set to No.  So Im just curious how the system put them there to begin with?  I completely understand all you have said, Im just trying to figure out why the system put them there.  Thanks..

Link to comment

I think this is down to the way the mv (rename) interacts with the Use Cache setting.

 

The Use Cache setting affects where new files are located.

 

Now consider the case where one of your downloaders downloads a file which uses the Use Cache setting to place the file on the cache drive.  All as expected.

 

Now you run some program to move/rename the file to some other share.    Now if possible Linux will just move the file to the destination on the same disk (which is not creating a new file but moving an existing one so the Use Cache setting has no effect) and only if that fails will it do a copy (which does create a new file so uses the Use Cache setting) and delete the original file.

 

So if the file to be moved is on the cache disk in the downloads share it will end up still on the cache disk after it has been moved to a share which has Use Cache set to No ..... unexpected, but a feature on the way the system works.

Link to comment

idk, just seems odd.  So running with this theory, do you think that after I download some files, and do something with them, before moving them to their final location, do you think I should run Mover, to get them out of the Cache folder, then do the moving around stuff that I do.  It just seems like a bug.  To me, and maybe I'm just looking at this to simplistically, if shares are set to not use the cache drives, any files going into that share, the system should know, don't put it on there, and if it was on there to begin with, then move them off.  Its not the end of the world, just behavior that I wasn't expecting.  I normally didn't use a cache drive before because there just wasn't enough room for the things I was doing, but then I said screw it and got 2x1TB SSD's and through them in, in Raid 0 just to test and play with it. 

Link to comment
12 minutes ago, ibbanez said:

To me, and maybe I'm just looking at this to simplistically, if shares are set to not use the cache drives, any files going into that share, the system should know, don't put it on there, and if it was on there to begin with, then move them off. 

This is a not uncommon misconception about the Use Cache setting.   It only applies to New files, not to existing files.   When you use the 'mv' command at the Linux level you are potentially by-passing the Unraid User Share system as Linux first tries to rename the file if it thinks it is on the same mount point, and only if that fails does it do a copy/delete operation.   Since as far as Unraid is concerned a file that is renamed is not a new file so you can end up with 'orphan' files for a share left on the cache drive.

 

The presentation for the Use Cache setting in the GUI has been altered for the 6.8.0 release to try and make this clearer.   I think it might also be worth expanding the GUI help associated with this setting but that has not yet happened.

Link to comment

A simpler workaround, instead of moving from a cached share to an uncached share, copy from source share to destination share, then delete from the source share. Copy will create a new file which obeys the user share settings. Move will just attempt to rename since move and rename are the same thing on linux.

Link to comment

Not knowing what all your shares are for and how you manage adding new files it is difficult to know 100% what is the best solution for you.

 

Personally I would just set your main shares which are fed from your download shares to Use Cache Yes, and then set mover to run at a schedule that suits your usage (or manually run mover if you want).    Then you don’t need to keep doing anything special and the system will just do the necessary stuff for you without you needing to take any additional actions.

  • Like 1
Link to comment
  • 1 year later...

I know the thread is 2 years old, but since I just searched for a solution about a similar problem and this thread poped up on quite a prominent position, I think I should share my findings:

 

If a share is set to use NO cache and you want to move/copy data from a cache drive to it, and you go from /mnt/user/whatever to /mnt/user/whateverother, unraid ends up writing the moved data to the cache drive, creating a /whateverother share on the cache, as if "use cache" was set to YES.

But the MOVER won't do anything, since the said share is actually set to NOT use cache. It won't take long until "Fix Common Problems" alerts you about this situation.

I don't have an answer on why it is doing this, but I have a ...

 

...Solution:

 

Move data from cache to shares that are set to "use chache: NO" by moving the files from /mnt/user/whatever to /mnt/user0/whateverother. Now the files get actually moved to said share (following the rules set up on how to write to the shares), without unraid trying to write to the cache first.

 

I hope that helps any future visitors to this thread,

cheers,

McFex

Link to comment
1 minute ago, McFex said:

I know the thread is 2 years old, but since I just searched for a solution about a similar problem and this thread poped up on quite a prominent position, I think I should share my findings:

 

If a share is set to use NO cache and you want to move/copy data from a cache drive to it, and you go from /mnt/user/whatever to /mnt/user/whateverother, unraid ends up writing the moved data to the cache drive, creating a /whateverother share on the cache, as if "use cache" was set to YES.

But the MOVER won't do anything, since the said share is actually set to NOT use cache. It won't take long until "Fix Common Problems" alerts you about this situation.

I don't have an answer on why it is doing this, but I have a ...

 

...Solution:

 

Move data from cache to shares that are set to "use chache: NO" by moving the files from /mnt/user/whatever to /mnt/user0/whateverother. Now the files get actually moved to said share (following the rules set up on how to write to the shares), without unraid trying to write to the cache first.

 

I hope that helps any future visitors to this thread,

cheers,

McFex


you would not get this problem if you use a ‘copy’ operation.     It occurs when you try and use a ‘move’ operation from the command line (or a Docker container) as the way Linux implements move can by-pass the UnRaid User Share system if Linux thinks both source and target are on the same mount point leaving the moved file on the same physical drive but in the new folder.

Link to comment
6 minutes ago, itimpi said:


you would not get this problem if you use a ‘copy’ operation.     It occurs when you try and use a ‘move’ operation from the command line (or a Docker container) as the way Linux implements move can by-pass the UnRaid User Share system if Linux thinks both source and target are on the same mount point leaving the moved file on the same physical drive but in the new folder.

 

Yeah, but in the end that means the extra step deleting the files at the source.

 

And as always it depends on the individual usecase scenario, which way fits best.

"user0" seems to be a good enough solution if you insist on moving rather than copying your files from cache to a share set to NOT use cache.

Link to comment
Just now, McFex said:

 

Yeah, but in the end that means the extra step deleting the files at the source.

 

And as always it depends on the individual usecase scenario, which way fits best.

"user0" seems to be a good enough solution if you insist on moving rather than copying your files from cache to a share set to NOT use cache.


yes - but UnRaid have said that there is a chance that /mnt/user0 may disappear in a future UnRaid release.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.