FreeMan Posted July 1, 2022 Share Posted July 1, 2022 (edited) My docker.img file is 30GB and is at 100% utilization as we speak. I know that the usual cause of this is poorly configured dockers that are writing things to the wrong path, however, this has been a long, slow fill, and I believe that I've simply filled space with logs or... something... over time as this hasn't been a sudden situation. I got the warning that I was at 91% about 2 weeks ago, but I've been away from the house and wasn't able to look into it, and it wasn't my #1 priority as soon as I returned home. I'm attaching diagnostics which will, I hope, point to what's filling the img file, in the hopes that someone can point me in the right direction of where to cull logs or whatever I need to do to recover some space. If it appears that I have, legitimately filled the img file, I'll recreate it and make it bigger. There are two potential culprits that I can think of: * I installed digiKam a couple of months ago. I had it load my library of > 250,000 images and I've begun cataloging and tagging them. I think that the database files that support this are on the appdata mount point and that they could be getting rather large. (Yes, I realize that I should probably migrate the DB to the mariaDB docker I've got, but that's still on my to do list, and even if I do, it will simply move the space utilized, possibly reducing it somewhat, but not eliminate it.) * I've been having issues with my binhex-delugevpn docker. It's been acting strangely and I noticed that when I restarted the container yesterday, it took about 15 minutes for it to actually properly start and get the GUI up and running. I had the log window open for a good portion of that time, and noted that it was writing quite a bit to that log. It's possible that it's filling and rotating logs and that these are using a fair bit of space. I'm looking into these two to see if they are causing issues, but I'd appreciate another set of eyes and any other tips/pointers on where I may be wasting/consuming unusual amounts of space, and recommended solutions. nas-diagnostics-20220701-1451.zip Edited July 1, 2022 by FreeMan the file was dropped in the middle of the text. moved it to the end for readability Quote Link to comment
FreeMan Posted July 1, 2022 Author Share Posted July 1, 2022 I think I found the problem. appdata\influxdb is 22.9GB. I believe the majority (if not all) of that is from "Ultimate UNRAID Dashboard" data. Short term, I think the best solution is to simply enlarge the .img file, while long term, I need to decide how much (if any) of that to actually keep. Still open to any other insights anyone may have. Quote Link to comment
trurl Posted July 1, 2022 Share Posted July 1, 2022 Go to Docker, click Container Size at bottom, post screenshot Quote Link to comment
FreeMan Posted July 1, 2022 Author Share Posted July 1, 2022 20 minutes ago, trurl said: Go to Docker, click Container Size at bottom, post screenshot Note that scrutiny is listed twice so I knew I didn't miss any lines. I was pretty sure that my docker file was 30GB, and my memory didn't fail me! If UNRAID says the containers only take 20.2GB, why is it reporting that I'm at 100% img file use when the image file is 30GB? Quote Link to comment
Solution trurl Posted July 1, 2022 Solution Share Posted July 1, 2022 3 minutes ago, FreeMan said: only take 20.2GB You also have to add in the other 2 column totals. Looks like scrutiny logs are pretty large, see if you can do anything about that. Since you have so many containers it wouldn't be unreasonable to increase docker.img allocation, but growth needs to be dealt with. 1 Quote Link to comment
FreeMan Posted July 1, 2022 Author Share Posted July 1, 2022 3 minutes ago, trurl said: You also have to add in the other 2 column totals. derp! That makes complete sense. 4 minutes ago, trurl said: Looks like scrutiny logs are pretty large I see that now. I glossed over that one. I'll see what I can do to trim those logs, and I may go ahead and up the img size, too. TYVM! Quote Link to comment
FreeMan Posted July 1, 2022 Author Share Posted July 1, 2022 Problem solved! There was some sort of issue starting the docker and it was spamming the log with its startup info. Heading off to the LS.IO support thread, I discovered that as of June, 2022, the docker has been deprecated! Since I hardly ever used it. I've stopped the docker and deleted the config. I'm now at 23GB out of 30GB used, and should be good to go for quite a while. Quote Link to comment
Recommended Posts
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.