unRAID OS Version: All versions with docker support

 

Description: Docker simply cannot handle if its install location runs out of space and unpredictable container issues ensue from this point onwards.

 

How to reproduce: With docker operating locate and fill up the drive that it is installed too 100%

 

Expected results: Graceful shut down of docker before it can no longer operate with an alert or meanigful log message.

 

Actual results: Docker containers become unstable and in many cases a container/image dependency breaks resulting in all limbs of that tree breaking. If you are unfortunate enough this could be a dependency of the donor OS image and as such will break everything.

 

Other information: Currently the only known fix is a the complete removal (manual as the webgui may not be able to handle the broken dependency) and reinstall of all containers and images.

 

 

 

We have a proposed solution to this:

http://lime-technology.com/forum/index.php?topic=34830.0

The change in -beta8 to make use of btrfs-formatted loop mounted volumes is a workaround for this issue.  At least we display the info to the user about how much free space remains, along with control to expand the volume file.

 

The volume file is initially created as follows:

 

If file system where volume is created on is:

o btrfs: we use fallocate to create and extend.  Upon creation we turn off COW for the file (not for the file system within the file).

o xfs: we use fallocate to create and extend.

o reiserfs:  we use truncate to create and extend.

 

Advantage of fallocate is that all the blocks for the image file are allocated, meaning it's not a sparse file.  This ensures that amount of free space displayed for the image is really free space.  reiserfs does not support fallocate so we must use truncate.  In this case the image file is sparse.

In b8 the docker containers are themselves is in an img file however if the drive the the config files (stuff mounted inside docker with -v) the applications will typically fail.

 

Since people typically store these files in the same place the net effect is docker still breaks if the drive fills.

 

I suggest the image idea is extended to the config files as well

In b8 the docker containers are themselves is in an img file however if the drive the the config files (stuff mounted inside docker with -v) the applications will typically fail.

 

Since people typically store these files in the same place the net effect is docker still breaks if the drive fills.

 

I suggest the image idea is extended to the config files as well

I think there is always going to be a problem if a drive (not the docker.img file) that is being used by docker runs out of space?  I can see the particular docker container will fail, but does the whole docker sub-system fail?  As I understand it you already have the option to store files inside the docker.img file in addition to the actual docker images.

 

Not sure how extending the image idea is going to help - if a physical drive fills up there is not much you can do except buy another/larger drive.  Perhaps you have something else in mind?

It makes sense when you consider unRAID is moving toward an "app in the box model" i.e. press a button and the app comes up.

 

In this model users dont care about the difference between docker and apps and configs and XML templates etc... all they care about is the app that came out the box still works.

 

If we have a second image  for "appdata" then nothing except the apps should consume the reserved space for the appdata making it far resistant to outside error.

 

It also means and backup and versioning controls that are added to the docker img can naturally be extended to the appdata as well.

 

p.s. i know you can hack about and acheive all this as-is I am referring to the shipped defaults.