devmapper: Add a new option dm.min_free_space

Once thin pool gets full, bad things can happen. Especially in case of xfs
it is possible that xfs keeps on retrying IO infinitely (for certain kind
of IO) and container hangs. 

One way to mitigate the problem is that once thin pool is about to get full,
start failing some of the docker operations like pulling new images or
creation of new containers. That way user will get warning ahead of time
and can try to rectify it by creating more free space in thin pool. This
can be done either by deleting existing images/containers or by adding more
free space to thin pool.

This patch adds a new option dm.min_free_space to devicemapper graph
driver. Say one specifies dm.min_free_space=10%. This means atleast
10% of data and metadata blocks should be free in pool before new device
creation is allowed, otherwise operation will fail.

By default min_free_space is 10%. User can change it by specifying
dm.min_free_space=X% on command line. A value of 0% will disable the
check.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

docs/reference/commandline/daemon.md

@@ -438,6 +438,32 @@ options for `zfs` start with `zfs`.
     when unintentional leaking of mount point happens across multiple mount
     namespaces.
 
+*  `dm.min_free_space`
+
+    Specifies the min free space percent in thin pool require for new device
+    creation to succeed. This check applies to both free data space as well
+    as free metadata space. Valid values are from 0% - 99%. Value 0% disables
+    free space checking logic. If user does not specify a value for this optoin,
+    then default value for this option is 10%.
+
+    Whenever a new thin pool device is created (during docker pull or
+    during container creation), docker will check minimum free space is
+    available as specified by this parameter. If that is not the case, then
+    device creation will fail and docker operation will fail.
+
+    One will have to create more free space in thin pool to recover from the
+    error. Either delete some of the images and containers from thin pool and
+    create free space or add more storage to thin pool.
+
+    For lvm thin pool, one can add more storage to volume group container thin
+    pool and that should automatically resolve it. If loop devices are being
+    used, then stop docker, grow the size of loop files and restart docker and
+    that should resolve the issue.
+
+    Example use:
+
+        $ docker daemon --storage-opt dm.min_free_space_percent=10%
+
 Currently supported options of `zfs`:
 
 * `zfs.fsname`

man/docker-daemon.8.md

@@ -475,6 +475,30 @@ By default docker will pick up the zfs filesystem where docker graph
 
 Example use: `docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker`
 
+#### dm.min_free_space
+
+Specifies the min free space percent in thin pool require for new device
+creation to succeed. This check applies to both free data space as well
+as free metadata space. Valid values are from 0% - 99%. Value 0% disables
+free space checking logic. If user does not specify a value for this optoin,
+then default value for this option is 10%.
+
+Whenever a new thin pool device is created (during docker pull or
+during container creation), docker will check minimum free space is
+available as specified by this parameter. If that is not the case, then
+device creation will fail and docker operation will fail.
+
+One will have to create more free space in thin pool to recover from the
+error. Either delete some of the images and containers from thin pool and
+create free space or add more storage to thin pool.
+
+For lvm thin pool, one can add more storage to volume group container thin
+pool and that should automatically resolve it. If loop devices are being
+used, then stop docker, grow the size of loop files and restart docker and
+that should resolve the issue.
+
+Example use: `docker daemon --storage-opt dm.min_free_space_percent=10%`
+
 # CLUSTER STORE OPTIONS
 
 The daemon uses libkv to advertise