User shares disappeared after changing cache settings on system share to "no"

[tvu]

Hi support,

 

I was trying to change cache settings for various folders because mover kept stalling so I was trying to reduce the amount of folders using the cache option.

 

Unfortunately, my array now says "There are no exportable user shares". Perhaps my cache and/or system folder was corrupted as a result? Please help. Thanks in advance!

 

Edited December 1, 2022 by tvu

[JorgeB]

A reboot should fix it.

[tvu]

Hi Jorge. I tried to reboot, but the shares still are not showing up

 

Any other ideas on how to get them back?

[JorgeB]

New diags please.

[tvu]

Hi Jorge. 

 

My apologies. I "rebooted" the array, but I just realized you meant to reboot the entire system. 

 

Just rebooted the server and the shares are back. Thank you for the prompt response. Much appreciated! 🙏

[tvu]

One quick follow-up q - should I leave "system" shares to prefer cache? Looks like it ended up being unchanged after reboot

[JorgeB]

Depends on your preference, usually after everything is on cache I recommend changing to cache=only.

[trurl]

Diagnostics would allow us to give you better advice on how to configure your shares for better performance and cache usage.

[tvu]

Hi trurl,

 

My apologies. Updated diagnostics after reboot attached.

 

I currently have 4x 4TB HDDs, 1x 1.5TB HDD, and a 240GB SSD as cache. 

 

But I've noticed the cache fills up quite fast, so I was thinking of expanding it to a larger pool of SSDs - maybe 2 or 3 that I can take from other unused systems to combine for around 1TB

 

I was thinking I would try to get all new uploads onto cache and just run mover 1x per day or less. And over time, I'd like to separate the HDD pools have some as cold storage and another pool as always-on for more frequent access. That way, I can try to reduce some power usage, but not sure if it makes a big difference tbh

 

Edited December 2, 2022 by tvu

[trurl]

Your appdata share has files on the array and is set to not use cache. Your system share has files on the array and is set to prefer cache. You want appdata, domains, system shares all on fast storage (cache) and set to stay there so docker/VM performance isn't impacted by slower array, and so array disks can spin down since these files are always open. domains share is all on cache and set to prefer so that one is OK.

 

Nothing can move open files so even if a share is set to prefer cache its files can't be moved to cache if they are open. You have to disable Docker and VM Manager in settings before they can be moved.

 

Also, mover won't replace files so if a file exists in both places they won't be moved and you will have to decide which to keep and clean that up manually.

 

Your share anonymized as 'm---a' (probably media) has files on cache but is set cache:no. Mover ignores cache:no and cache:only shares, so those files still on cache won't be moved. You need to set it to cache:yes to get it moved, then you can set it cache:no if you don't want any new files to go to cache.

 

42 minutes ago, tvu said:

expanding it to a larger pool of SSDs - maybe 2 or 3 that I can take from other unused systems to combine for around 1TB

42 minutes ago, tvu said:

run mover 1x per day or less

 

Best approach is one pool for caching files that will be moved to the array, large enough to hold all you need to cache between mover runs. Running mover more often typically won't help with filling cache. It is impossible to move from fast cache to slow array as fast as you can write to fast cache. Mover is intended for idle time, once per day in the middle of the night is default for a reason.

 

And a smaller separate pool for appdata, domains, system and maybe for anything else you want to have quick and frequent access to.

 

SSDs for pools and HDDs for array. Note that you will need to backup anything staying on pools. There are plugins, for appdata backup, for example.

 

 

[tvu]

Hi trurl,

 

Thanks for the advice!

 

I changed the share settings today and things seem to be running a lot better now.

[trurl]

Post new diagnostics if you want me to take another look

[tvu]

Ok, sure. Please see attached.

 

I swapped the cache drive for a larger SSD that I had. I may add another and do raid 0 to increase the total cache size. 

 

But after I changed the cache settings on the various share folders, I ran the mover and now things seem to be running smoothly. Happy to take any additional advice on how to make the system more performant though. 

 

Thanks for your help!

unraid-diagnostics-20221202-0535.zip

[trurl]

Your system share still has files on the array.

23 hours ago, trurl said:

Nothing can move open files so even if a share is set to prefer cache its files can't be moved to cache if they are open. You have to disable Docker and VM Manager in settings before they can be moved.

 

Also, mover won't replace files so if a file exists in both places they won't be moved and you will have to decide which to keep and clean that up manually.

 

You can see how much each share is using on each disk by clicking Compute.. for the share on the User Shares page. 

 

1 hour ago, tvu said:

raid 0 to increase the total cache size. 

Unless the drives are the same size you want to use Single mode 

 

https://wiki.unraid.net/Manual/Storage_Management#Change_Pool_RAID_Levels

[tvu]

It's the libvirt.img file that's sitting on disk and can't move to cache.

 

But I don't currently run any VMs and I tried to disable it in settings and then delete the libvirt file, but it says the file is in use. Rebooted and tried again, but still can't seem to delete it. 

 

Any ideas? I'm fine to leave it on disk since I'm not using VMs. Ideally, I could just delete it entirely. Definitely want to avoid 1GB of disk space wasted on the cache though

 

[trurl]

2 hours ago, tvu said:

disable it in settings

According to those diagnostics VM Manager was enabled.

[tvu]

Yeah, after you pointed out that the system shares is still split between cache and disk1, I turned off VM Manager and rebooted. It's off now and I try to delete libvirt.img but the system says it's in use and can't be deleted

 

Doesn't seem like a huge deal though. Not urgent to solve it since the libvirt is just sitting on disk and I'm not using VMs right now

 

Thanks again for your help! Let me know if you have any other ideas on what it could be

 

Separately, one of my docker apps - qbittorrent webui stopped being accessible for some reason (it's on port 8080). Is it something to do with port forwarding settings on my local router? I can start a new thread on this if this isn't a common issue with an easy answer

[trurl]

What do you get from command line with this?

ls -lah /mnt/user0/system

 

[tvu]

root@unraid:~# ls -lah /mnt/user0/system
/bin/ls: cannot access '/mnt/user0/system': No such file or directory

 

[tvu]

Just re-checked and all the system folder is on cache now, including the libvirt.img file that doesn't seem necessary

 

Tried deleting again but get this error - The operation can’t be completed because the item “libvirt.img” is in use.

 

New diagnostics attached, if helpful

 

Edited December 4, 2022 by tvu

[trurl]

Have you tried rebooting?

[tvu]

Yes. I have rebooted multiple times since turning off the VM Manager setting. Still does not allow deletion of the libvirt.img file

[trurl]

VM Manager should be the only thing accessing that file.

14 hours ago, tvu said:

root@unraid:~# ls -lah /mnt/user0/system
/bin/ls: cannot access '/mnt/user0/system': No such file or directory

 

That just shows it doesn't exist on the array.

 

What do you get from this?

ls -lah /mnt/cache/system

 

[trurl]

Are you using the command line to delete the file?

[tvu]

8 hours ago, trurl said:

Are you using the command line to delete the file?

 

This was the ticket. I was trying to use delete from the network drive. 

 

rm libvirt.img

worked without issue from the console

 

Thanks again for all your help! New to unraid, so still figuring things out 🙏