Share ... references non existent pool cache


Recommended Posts

I got these strange warnings from FCP, how do I fix it?

 

I have no cache pool and have never had one, don't know what caused the issue.

 

The settings for the shares are prefer: cache for some and yes: cache for others, but they worked for few years without problems (already set up for if I ever wanted to add cache).

 

image.thumb.png.3a43a71abcb34fcdeff59c7ac744fb03.png

Edited by Fedeöä
Link to comment
3 hours ago, Fedeöä said:

I got these strange warnings from FCP, how do I fix it?

 

I have no cache pool and have never had one, don't know what caused the issue.

 

The settings for the shares are prefer: cache for some and yes: cache for others, but they worked for few years without problems (already set up for if I ever wanted to add cache).

 

image.thumb.png.3a43a71abcb34fcdeff59c7ac744fb03.png


this is a new warning in FCP and it sounds as if there may still be a few edge cases to be correctly handled.

Link to comment
2 hours ago, ChatNoir said:

From the diagnostics I see some shares pointing to 'cache-ssd' as it should, but many still point to 'cache' :

  • appdata
  • c-----s
  • domains
  • isos
  • l-------b
  • system
  • t-------------------------f
  • u----------------s

 

I've never touched any cache settings since setting up the system and I mostly only ever change docker applications here and there, but shares have been mostly untouched.

 

That's very, very odd, because I've checked each and every one of these and they're all showing the correct info. And this warning just started showing 1-2 days ago. I'd never seen that before.

 

Example of the appdata share:

image.thumb.png.81168d0e7f8446f0d914d4ccba127b83.png

 

Link to comment
1 hour ago, bonienl said:

Be aware that the actual reference may be different, and the GUI in this case shows the first possible choice.

You can make a change in the settings (and revert) to force a update and ensure the correct reference is used.

 

And that's part of the reason why this test is catching things that at first glance appear to be correct but would actually not have the desired effect the user wants without making a change.  Would the better course of action be to display what it's actually set to in Share Settings and then put up some red text saying pool doesn't exist?

Link to comment
1 hour ago, bonienl said:

Be aware that the actual reference may be different, and the GUI in this case shows the first possible choice.

You can make a change in the settings (and revert) to force a update and ensure the correct reference is used.

 

Here's the thing, though. There are no other options whatsoever :(

 

There's only one cache in my system - and there was only ever one - and it's the correct name. I've tried expanding the cache options to change to something else and try to get back to this, but I don't even get a choice.

 

The funny thing is that the cache is being used successfully as I've transferred some data a few weeks ago and checked the cache speed and it was filling up nicely.

Link to comment
3 hours ago, Digaumspider said:

I've never touched any cache settings since setting up the system and I mostly only ever change docker applications here and there, but shares have been mostly untouched.

And in this case the system isn't doing what you want it to do and FCP is catching that.  Your appdata share only exists on disk 1 and FCP caught that because of a config mistake / GUI bug or confusion (depending upon how you think about it)

Link to comment
6 hours ago, ChatNoir said:

Have you tried to set the share as Use cache to No, Apply.

Then set it back to Yes or Prefer depending on your use case, adjust the Pool if possible then Apply ?

 

Do that on one share, export new diagnostics and check the cfg file to see if it fixes the issue.

If you are not sure, you can check this new diag and tell us which share you changed.

 

I noticed the same thing, the unraid UI showed that the cache pool was correct, and no other option existed in the dropdown. FCP stated I was using a different pool. 

 

I just did something similar: 

Change the "use cache pool" option to any other option, then back to what I had it set to. Did not save changes until it was set back to Prefer (setting I had initially). This made the "apply" button active. 

After applying the settings I rescanned in FCP and boom, errors gone. 

 

 

 

Essentially, make any change in the share settings that allows you to be able to click the Apply button and click apply. The UI showed these shares of mine as using the pool Cache but for some reason they weren't. 

 

 

 

Here's my share showing only one cache pool - 

image.thumb.png.d8abd0cf9e56c21e5cb24a178c6f285e.png

 

 

And FCP notifying me about how it's using a different pool -
image.png.da868bb590addfa8073f0177ab424bde.png

 

And my one and only cache device - 

image.png.113370fdcde695d04c809dcf3ce89f49.png

 

 

 

 

  • Like 1
Link to comment
14 hours ago, Squid said:

And in this case the system isn't doing what you want it to do and FCP is catching that.  Your appdata share only exists on disk 1 and FCP caught that because of a config mistake / GUI bug or confusion (depending upon how you think about it)

 

15 hours ago, ChatNoir said:

Have you tried to set the share as Use cache to No, Apply.

Then set it back to Yes or Prefer depending on your use case, adjust the Pool if possible then Apply ?

 

Do that on one share, export new diagnostics and check the cfg file to see if it fixes the issue.

If you are not sure, you can check this new diag and tell us which share you changed.

 

Thank you both!

 

Just made those changes to force an apply and ran the tool again. Guess what? No more errors!

Seems like this is quite the bug in unraid, then and thanks to FCP, it's being picked up (my suggestion is to add the info that you may need to change the settings and back to the original ones to reapply the settings - to the problem description).

 

Thanks again for this!

  • Like 1
Link to comment
  • 8 months later...

To revive this - important also when you first setup a sever, the above happens.  GUI looked like it was pointed to the correct cache pool, but this was indicating it wasn't, and the turning off then back on corrected the error.  I guess this would be because setting up a new cache/ssd when  you first create the server is basically the same as renaming it?  From all appearances it looked correct and I would have had no idea anything was wrong  

Link to comment
  • 1 year later...

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.