Hi folks, 

I'm having an issue starting or more importantly finding docker containers that i had running after a reboot. 

I had quite a lot of containers as you can see in this screenshot, and as i said they've "vanished". I've also attached my diagnostics file.

tower-diagnostics-20230111-0059.zip

Unrelated, but SSDs in the parity array cannot be trimmed. Nothing assigned as cache, I assume that is expected since your array is SSD.

 

Why do you have 500G docker.img? 20G is often more than enough. Have you had problems filling it?

 

Looks like docker.img may be new since it doesn't have much in it. Can you tell us more about how you got to this point?

 

What do you get from command line with this?

ls -lah /boot/config/plugins/dockerMan/templates-user

 

 

Hi thanks for this, i think i figured it out from a good old google! Looks like it was realted to the docker img being located in /user/ vs. /volume/ aka disk1. So when the parity disk was trimmed, (it seems they do support trimming now btw). It was cleaning up the docker img from the parity and causing loads of issues, seems like two steps forward and one step back sometimes with Unraid changes  

I also use a large docker image as sometimes i work with huge datasets and need the space, haven't in a while but saves me stopping all dockers to bump up the img size.  

Post changing the location of the docker img, i did a restore from "previous apps" under the App section. 

Edited January 11, 20233 yr by Inch

3 hours ago, Inch said:

So when the parity disk was trimmed, (it seems they do support trimming now btw). It was cleaning up the docker img from the parity

Parity doesn't know anything about files, it's just a bucket of bits that completes an equation with all the array disks. If ANY array disk was trimmed without the affected bits being accounted for in parity it would invalidate parity, causing potential corruption if a disk was rebuilt, and parity checks subsequent to the trim event would have errors.

 

 

4 hours ago, Inch said:

docker img being located in /user/ vs. /volume/ aka disk1.

/user and /volume are not persistent paths in Unraid, and /volume is not a path to any disk or user share.

 

Perhaps you mean a user share path such as /mnt/user/system vs. a disk path such as /mnt/disk1/system. Either should work.

 

4 hours ago, Inch said:

when the parity disk was trimmed, (it seems they do support trimming now btw

Do you have a link for that? Even if true, the rest of your explanation doesn't make any sense since parity doesn't contain any data.

 

4 hours ago, Inch said:

use a large docker image as sometimes i work with huge datasets

Any huge dataset should be mapped to host storage and not created inside docker.img . Lots of people get by with 20G docker.img whatever they are doing.

 

4 hours ago, Inch said:

restore from "previous apps"

That was the reason for my question

17 hours ago, trurl said:

What do you get from command line with this?

ls -lah /boot/config/plugins/dockerMan/templates-user

since those templates are where previous apps gets the information for the create/edit container page to recreate your dockers.

19 hours ago, trurl said:

/user and /volume are not persistent paths in Unraid, and /volume is not a path to any disk or user share.

 

Perhaps you mean a user share path such as /mnt/user/system vs. a disk path such as /mnt/disk1/system. Either should work.

 

Any huge dataset should be mapped to host storage and not created inside docker.img . Lots of people get by with 20G docker.img whatever they are doing.

Thank you for this, I'm going to go away and make changes per this threads reccomendation! Really appreciate the help here, what i suspect was happening is since my docker img file was so large, it was creating it, and then maybe reducing the size (to the actual needed size) vs. trimming? Unsure though.

Also RE SSD Trim: https://www.reddit.com/r/unRAID/comments/xog67u/dynamix_ssd_trim/

Edited January 12, 20233 yr by Inch