If I run
fstrim in a docker container I get errors about host-mounted(?) files being
not a directory.
$ docker run -ti -v tmp:/tmp2 ubuntu:16.04 /sbin/fstrim --all fstrim: /etc/hosts: not a directory fstrim: /etc/hostname: not a directory fstrim: /etc/resolv.conf: not a directory fstrim: /tmp2: FITRIM ioctl failed: Operation not permitted
I’m guessing this is because the container isn’t privileged. (at least the
FITRIM ioctl failed error)
I discovered this by installing
cron on a fresh
ubuntu:16.04 container (I know it violates the “one process” philosophy – that’s another discussion) But the default image has
/etc/cron.weekly/fstrim so once you install cron,
fstrim starts running weekly and cron emails me the errors.
Should I be running
fstrim in a container?
I’m still wrapping my head around
aufs and all the pages I found about
fstrim talk about SSDs and free space recovery.
Does any of this apply in a container? Won’t the host’s fstrim cron job take care of everything? Should I remove the cron job from the container or is a bug in docker?
edit: system info:
$ uname -sri; docker --version Linux 4.4.0-53-generic x86_64 Docker version 1.12.3, build 6b644ec
fstrim makes absolutely no sense inside a container.
The point of
fstrim is to unmap unused storage on the backing store, whether that’s a local SSD or thin provisioned SAN storage mounted via iSCSI, FibreChannel, or whatever. Such a process needs to run on the host, rather than inside a container.
The specific errors you see are because
fstrim attempts to call the FITRIM ioctl on each mount point, and mount points inside a container do not correspond to the actual block devices the host is using. This is generally true even if the container is privileged.
Why Ubuntu puts
fstrim in a container image is a complete mystery. If you’re stuck with Ubuntu containers, I would suggest disabling that cron job.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.