Containers with a lot of traffic in /tmp

We’re currently having a small issue and i’m not exactly sure what is the best way to solve it. Perhaps someone can enlighten me:
We’re running Docker >1.10 (one 1.10, one 1.12.2, but that doesn’t matter).
Graph driver is devicemapper with direct lvm.

There’s a MySQL container running… Of course, data files are mapped into volumes, but /tmp is located inside the container.
On big imports there’s a lot going on inside /tmp, which results in an inflating MySQL container ( as you know, even when fs-blocks are not used anymore, they are not released).
So I do housekeeping every week and throw some fstrim’s on those containers root-fs, killing all that c-o-w history…

I know there’s an option to let docker-daemon do this on the fly but people told me that this dramatically impacts performance.

Now I want to tweak the MySQL container. Since 1.10 there’s a --tmpfs option, usually used in conjunction with --read-only ( does this impact write access to mounted volumes, like mysql’s data volume?).

I don’t want to map /tmp to some OS volume, because I don’t want to care about tmp data and keep containers as flexible as possible.

–tmpfs is using Ram, I don’t nessecarily need to occupy ram for that.

Any way to keep a non-persistent, performant volume outside devicemapper’s access? (without using ram?)

Or is tmpfs the only way to go ?

best regards,
Björn

did you ever come up with a solution?