Right now devicemapper mounts thin device using online discards by default
and passes mount option "discard". Generally people discourage usage of
online discards as they can be a drain on performance. Instead it is
recommended to use fstrim once in a while to reclaim the space.
In case of containers, we recommend to keep data volumes separate. So
there might not be lot of rm, unlink operations going on and there might
not be lot of space being freed by containers. So it might not matter
much if we don't reclaim that free space in pool.
User can still pass mount option explicitly using dm.mountopt=discard to
enable discards if they would like to.
So this is more like setting the containers by default for better performance
instead of better space efficiency in pool. And user can change the behavior
if they don't like default behavior.
Reported-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 04adaaf1ee1688ff48cb8f541dcb80e965f45080
Component: engine
Make use of iptablesPath variable which has the path of iptables, instea...
Upstream-commit: 5221fd2ba5fbf78ad7a5d4edf039d54ae32141ef
Component: engine
Minor thing but docker cp --help was:
Copy files/folders from a PATH on the container to a HOSTDIR on the host
running the command. Use '-' to write the data
as a tar file to STDOUT.
This changes it to:
Copy files/folders from a PATH on the container to a HOSTDIR on the host
running the command. Use '-' to write the data as a tar file to STDOUT.
The \n made the output look funky.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 68ee5bdf96f1653d73e29329506949a765398a40
Component: engine
This patch modifies the journald log driver to store the container ID in
a field named CONTAINER_ID, rather than (ab)using the MESSAGE_ID field.
Additionally, this adds the CONTAINER_ID_FULL field containing the
complete container ID and CONTAINER_NAME, containing the container name.
When using the journald log driver, this permits you to see log messages
from a particular container like this:
# journalctl CONTAINER_ID=a9238443e193
Example output from "journalctl -o verbose" includes the following:
CONTAINER_ID=27aae7361e67
CONTAINER_ID_FULL=27aae7361e67e2b4d3864280acd2b80e78daf8ec73786d8b68f3afeeaabbd4c4
CONTAINER_NAME=web
Closes: #12864
Signed-off-by: Lars Kellogg-Stedman <lars@redhat.com>
Upstream-commit: 869ecba652294e069874c83591d6f1b469d7cc32
Component: engine
prioritize the ports with static mapping before dynamic mapping. This removes
the port conflicts when we allocate static port in the reserved range
together with dynamic ones.
When static port is allocated first, Docker will skip those when determining
free ports for dynamic ones.
Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com>
Upstream-commit: cd2b019214eb1978ae267786668dc7a8a3702679
Component: engine
More systemd goodness. Documenting where `docker.service` lives under Ubuntu 15.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Upstream-commit: c0a1b2d6e99d5c6e29a016da39c1313a54c1cb34
Component: engine
We encountered a situation where concurrent invocations of the docker daemon on a machine with an older version of iptables led to nondeterministic errors related to simultaenous invocations of iptables.
While this is best resolved by upgrading iptables itself, the particular situation would have been avoided if the docker daemon simply took care not to concurrently invoke iptables. Of course, external processes could also cause iptables to fail in this way, but invoking docker in parallel seems like a pretty common case.
Signed-off-by: Aaron Davidson <aaron@databricks.com>
Upstream-commit: c271c61feea7d3ea3fcbb3af9f0d9c1f641a8d82
Component: engine
