Constant writes to array possibly docker?

[Nozlo]

Hello,

 

I have a two parity array with two disks on the array that are constantly writing and cant seem to figure out/fix the issue. I have appdata moved onto the cache drive with an appdata backup service running. After running the mover array --> cache multiple times it still doesn't seem to get everything off of the array and onto the cache drive.

 

One thing to note it looks as if the docker default appdata location is /mnt/user/appdata/ I did try to change this to my cache and it reset all of my docker containers and had to re-map to the original location.

 

[itimpi]

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback.  It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

[Nozlo]

12 hours ago, itimpi said:

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback.  It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

That would most definitely help. Attached is the diagnostics zip.

 

To add - I had other appdata directories on different disks that were old and unused containers. I manually deleted them and on those disks the constant writes appear to have stopped. The last disk is disk2 which remains to constantly r/w with an appdata directory containing a plex media server folder. For some reason, the mover will NOT move this directory off of the array even with disabling docker. I have also turned the plex container off and the r/w continue.

homeserver-diagnostics-20231213-1620.zip

[itimpi]

1 hour ago, Nozlo said:

For some reason, the mover will NOT move this directory off of the array even with disabling docker.

Normally this means you have duplicate files as mover will never overwrite an existing file.  If everything is functioning correctly this scenario does not arise, but it might if you have had drives unexpectedly dropping offline.   In such a case you have to manually decide which copy to keep and delete the other one.

[Nozlo]

17 hours ago, itimpi said:

Normally this means you have duplicate files as mover will never overwrite an existing file.  If everything is functioning correctly this scenario does not arise, but it might if you have had drives unexpectedly dropping offline.   In such a case you have to manually decide which copy to keep and delete the other one.

Sounds good. Went ahead and deleted that appdata directory on disk2 manually.

 

It looks like the disk continues with constant writes. I have file activity plugin installed and enabled and it shows absolutely nothing. Could the constant writes on disk2 with both parity's just be normal?

[itimpi]

5 minutes ago, Nozlo said:

It looks like the disk continues with constant writes.

Your ‘system’ share was on disk2 in the last diagnostics, and that share contains the docker,img file which is probably causing your issue.   You normally want that share to be on a pool if at all possible both to minimise array reads/writes and also maximise  performance of docker containers..

[Nozlo]

38 minutes ago, itimpi said:

Your ‘system’ share was on disk2 in the last diagnostics, and that share contains the docker,img file which is probably causing your issue.   You normally want that share to be on a pool if at all possible both to minimise array reads/writes and also maximise  performance of docker containers..

Gotcha. Shutdown docker, set system share to cache only, run mover and in theory problem solved? I am assuming docker will need to be told where the vdisk was moved to?

 

edit: Moved system share over to cache drive and will figure out backup solutions. Looks like no more unnecessary read / writes are on the array! Thanks for your help!

Edited December 14, 2023 by Nozlo

[itimpi]

1 hour ago, Nozlo said:

I am assuming docker will need to be told where the vdisk was moved to?

No change should be required as it references it via the user share name which remains valid.