Good evening everybody,

I'm a relatively new user of unraid (less than two months), and I'm still learning the ins and outs of the system. So far, I'm loving it; definite upgrade for me from running some docker containers haphazardly in Ubuntu.

 

I'm having an interesting issue (to me), that I've been unable to resolve. I've searched through the forums here as best I can, and I've also google'd a bit, and I can't find a solution. I may have missed it posted here somewhere, so my apologies if I've overlooked it.

 

Last night, I removed one of my two cache drives (before removal, there were 2x250GB SSDs in the pool). I found a walkthrough (found here), and followed it step by step. Currently, one of those two 250GB drives remains. This remaining drive is the first drive I ever added to my machine, and ran with just that drive for a while before I put a second one in. I added the second because I wanted to get more cache space, not understanding that's not how it works, and just decided to leave well enough alone. This second drive, in addition to another caching drive that I used [edit, 922pm 8/6: in a separate cache pool for transcoding], was removed to allow for two more drives for the array (I need a new PSU; I'm missing sata power cables).

 

The issue I'm having currently, is my remaining cache drive is showing a usage of about 70-75GB after mover has run and nothing else is being put onto the cache. Prior to the removal of my second cache drive, it sat somewhere between 20-25GB of usage (based on my recollection). I have a script to invoke the mover once the cache hits 75% or more full, checking once an hour. Prior to yesterday/today, this script worked as advertised without issue. Manually invoking the mover does not lower it past this 70-75GB point.

 

My cache pool is using btrfs, and after removing the drive and restarting the array, it began "doing its thing". However, the automove script ran once during that process. I completely forgot to turn that off prior to this drive removal. I don't know if it caused an issue during the removal process, but I didn't know how to stop the mover from running once it was going and felt it best to just leave everything alone to finish so I hopefully don't screw anything up [further]. The removal process took around 2 hours to finish; I don't know if this is normal, or if the mover running delayed its completion.

 

This may be my inexperience with unraid that's causing me to not be able to figure it out, but I don't know how to determine where all this extra usage is coming from. I looked in unbalance to see if there's any folders that look incorrect, and nothing there sticks out. I tried looking through things through Krusader, and nothing is sticking out to me there either (but, I might not know what to look for). I'm not knowledgeable enough to know what commands to run in the CLI, so maybe there's something there I can check?

 

I've attached the diagnostics report to this post; how to dig into it to decipher anything is beyond me. I'm not sure if this will show up, but you may find an unused 10TB disk in the report. This is intended to be my parity drive in the immediate future. I just got the two 10TB drives hooked to the machine, yesterday.

 

To my knowledge, I have included all relevant details that I can think of at the moment.

 

Any assistance that any of you can provide would be infinitely appreciated. If I've missed including anything that would shed light on my issue, please let me know and I will promptly provide it to you if I can.

 

Thank you in advance for your time.

 

-Chris/Sumi

unlazarusraid-diagnostics-20210806-2052.zip

Edited August 7, 20214 yr by sumidor063

Why have you given 40G to docker.img? Have you had problems filling it? 20G is usually more than enough and if you have been filling it, making it larger will only make it take longer to fill. The usual cause of filling docker.img is an application writing to a path that isn't mapped.

 

Your system share has some files on the array instead of all on cache as it should be. Maybe you enabled dockers or VMs when you didn't have cache installed so some of system share got created on the array. Looks like maybe libvirt is the culprit here. Try disabling VM Manager in Settings before running mover to see if it will get moved to cache where it belongs. Do you actually have any VMs yet?

 

Usually appdata, domains, and system shares are cache-prefer (or cache-only), so dockers/VMs will perform better and not keep array disks spunup. Those shares are set correctly, but as mentioned, system has some files on disk1.

 

You have another share anonymized in diagnostics as p-----------e which is also cache-prefer. What is the purpose of that share and why do you want it to stay on cache?

 

Your other share which still has files on cache is p--------a, but that one is cache-yes, so those should get moved to the array unless they are open or duplicates.

 

All things considered, the amount of cache used seems about right, and the removal of that other cache disk seems to have worked OK.

 

As you found, the default btrfs configuration produced a mirror, but it is possible to do it differently and get the total capacity as you were wanting.

 

Running mover more frequently is not necessarily the best way to deal with cache space. Mover is intended for idle time. It is impossible to move from fast cache to slower array as fast as you can write to cache, and if mover is running while new files are being written to cache, it is just going to be competing for those resources.

1 minute ago, trurl said:

Why have you given 40G to docker.img? Have you had problems filling it? 20G is usually more than enough and if you have been filling it, making it larger will only make it take longer to fill. The usual cause of filling docker.img is an application writing to a path that isn't mapped.

I'm going to be perfectly honest with you, I don't recall setting it to 40GB (but I obviously did as I assume that's not the default setting) and have no active reason for it to be that large, to my knowledge. If I bump it back down to 20, will it cause any issues now that it's been set to 40?

1 minute ago, trurl said:

 

Your system share has some files on the array instead of all on cache as it should be. Maybe you enabled dockers or VMs when you didn't have cache installed so some of system share got created on the array. Looks like maybe libvirt is the culprit here. Try disabling VM Manager in Settings before running mover to see if it will get moved to cache where it belongs. Do you actually have any VMs yet?

I do not have any VMs on my rig, no. And at this time I'm not looking to add any. In the future, sure, but not right now. Before continuing on with the rest of this reply, I disabled VM Manager and ran the mover, and there was minimal, if any, change in the amount used on the cache.

1 minute ago, trurl said:

 

You have another share anonymized in diagnostics as p-----------e which is also cache-prefer. What is the purpose of that share and why do you want it to stay on cache?

The P-E share is unused currently. This is the share I set up for transcoding purposes, on its own cache pool. Not sure if that was the best way to go about it, but it worked at the time. I intend on removing it. There shouldn't be anything in there of any value to me and nuking it shouldn't be an issue. I just haven't stopped the array to do so yet (based on the available options in the main shares screen and the P-E share while the array is running, it has to be stopped first, yes? Apologies, I'm still learning).

1 minute ago, trurl said:

 

Your other share which still has files on cache is p--------a, but that one is cache-yes, so those should get moved to the array unless they are open or duplicates.

The P-A share is the one I actively use after reconfiguring some things regarding my media storage. This share is where all of my media resides.

1 minute ago, trurl said:

 

As you found, the default btrfs configuration produced a mirror, but it is possible to do it differently and get the total capacity as you were wanting.

Forgive me for my lack of knowledge, but would this mirror you refer to be residing as... "duplicate", I suppose, of the data that was on the second drive, and existing from having removed the second drive? Is this mirror something that can be removed, and do I even want to remove it?

1 minute ago, trurl said:

 

Running mover more frequently is not necessarily the best way to deal with cache space. Mover is intended for idle time. It is impossible to move from fast cache to slower array as fast as you can write to cache, and if mover is running while new files are being written to cache, it is just going to be competing for those resources.

With this, your recommendation is that I cease use of the automove script? I don't object to this at all. There are times where I am throwing onto the cache drive at considerable rates, so the cache will fill up pretty easily. I added the script in an attempt to continue to use the cache drive as much as possible, but perhaps that's a pointless effort?

 

Thank you very much for your insight above, and for any other information you're willing to provide for me.

 

-Chris

14 hours ago, sumidor063 said:

If I bump it back down to 20, will it cause any issues now that it's been set to 40?

Not necessary unless you just want to recover that space. If you do change it you will have to recreate docker.img, which isn't really a problem since Previous Apps on the Apps page will reinstall your dockers exactly as they were.

 

14 hours ago, sumidor063 said:

I do not have any VMs on my rig

Then you don't need to enable VM Manager. Disable it then delete libvirt.img from that same page. It isn't very large so you wouldn't have noticed much difference if it moved.

 

14 hours ago, sumidor063 said:

The P-E share is unused currently. This is the share I set up for transcoding purposes, on its own cache pool. Not sure if that was the best way to go about it, but it worked at the time. I intend on removing it. There shouldn't be anything in there of any value to me and nuking it shouldn't be an issue. I just haven't stopped the array to do so yet (based on the available options in the main shares screen and the P-E share while the array is running, it has to be stopped first, yes?

Your diagnostics don't show any other pool besides the one named cache, that share is set to use the cache pool, and it has files on cache. If you stop the array you literally can't access any files, so they have to be deleted with the array started. After you delete the contents, the share can be deleted from its page accessed by clicking on it on User Shares page.

 

14 hours ago, trurl said:

default btrfs configuration produced a mirror, but it is possible to do it differently and get the total capacity as you were wanting.

Default is btrfs raid1, which is a mirror, meaning there is another copy of everything on the other disk(s). See here for other options:

 

14 hours ago, sumidor063 said:

There are times where I am throwing onto the cache drive at considerable rates, so the cache will fill up pretty easily.

My recommendation: if you are writing more at one time than cache can hold then don't cache.

trurl,

 

Thank you very much for the help you've provided me. I'm going to go forward with your recommendations, and keep your suggestions in mind. Thank you!!!

 

-Chris

 

[Edit 1]: I now realize that if a share is to be removed, all of its contents have to be deleted. I just cleared it through Krusader and it gave me the option to delete the share. Apologies for my misunderstanding!

Edited August 8, 20214 yr by sumidor063

@trurl

I have done some more playing around and found that a large part of my problem was related to my Plex library, and the phototranscoder cache. Currently, it's eating up about 30GB of the space I was expecting to have access to. I will get something set up to automatically nuke any portion of that cache older than a few days. Prior to today, I wasn't aware that that cache existed and that it can easily take up massive amounts of space.

I thank you again for your assistance!

 

-Chris

Edited August 14, 20214 yr by sumidor063