High IOPS value (save operation to disc)

[kruuger]

Hello,
I installed gluetun thru docker on my drive 3.
Of course mapped volume to this drive.

But not sure why after run container, gluetun start to write something on my drive 1 and 2 (raid 1).
IOPS value is 20-30 operation. Hard drives "scratches" like crazy.

My question is, why and what kind of informations are saved to drive?
Also why drive 1 and 2, when in configuration drive 3 was selected?
Are there any logs or additional info saved to drive?
My drive 1 and 2 is used only for system application but not for docker containers.

Thanks for any tips.

Attached image - red gluetun starts, green when turned off.

[frepke]

What does the next command say:

docker info | grep "Docker Root Dir"

[kruuger]

these are return:

which docker:
/usr/local/bin/docker

sudo docker info | grep "Docker Root Dir"
 Docker Root Dir: /volume1/@docker

[frepke]

The second command say that your docker containers lives on your volume1. If that's your raid drive, then it's normal to see some action here.

[kruuger]

The second command say that your docker containers lives on your volume1. If that's your raid drive, then it's normal to see some action here.

Yes, the docker application itself (synology Container Manager) are installed on volume1 (drive 1 & 2)

Can a container mapped to a different volume still interact with the main volume1?
volumes: - /volume2/docker/gluetun-pl:/gluetun

I have a few other containers running, and their IOPS is zero, with no writes to the "system" volume1.
The Gluetun container is running but is not currently used by any other container.
I'm trying to figure out the high IOPS on my drive, and for now, Gluetun seems to be the culprit. It's strange that it writes something without any apparent reason.

[frepke]

volumes: - /volume2/docker/gluetun-pl:/gluetun means that the internal folder /gluetun from the container is mapped to - /volume2/docker/gluetun-pl

sudo docker info | grep "Docker Root Dir" Docker Root Dir: /volume1/@docker means that your container is running in /volume1/@docker and probably the IOPS are the result from a healtcheck or something (but the master @qdm12 can tell you more about it)