Niklas

No. MariaDB gives me the biggest impact because of constant (but very small) changes happening almost all the time. I don't think this is specific to any docker. All writes to the cache ssds formatted as btfs will see like 10-100 times more unexpected data written..... Containers that write or change more data will be noticed much more. Like plex or MariaDB. Writes to docker.img and /cache gives this write amplification

And it is not only writes to docker.img, seeing amplified writes to appdata (on cache) too. If I put my MariaDB databases in appdata I will get several gigs written every hour. Even with really small changes to the databases. I have had to move the Mariadb dir with databases from appdata to one of my unassigned devices to save some wear and tear on my ssds. I would like to move it back to appdata asap but I also want my hardware to live longer. My drives have 5 years of warranty OR 400+ in TBW. I really want to retain the warranty for at least 5 years but if this strange writes continues, people will have lots of drives out of warranty here because of reaching the warranty tbw limit, fast. My drives are dedicated nas drives, hence the 400+ tbw limit but I will guess that most users use more ordinary brands like Samsung where the limit could be as low as 140 TBW. With this black hole of writing, they could be out of warranty in under a year. That's why I switched from Samsung to Seagate IronWolf ssds.

No Samsungs here. (Seagate IronWolf 110 SATA SSDs)

To revert from beta22 you have to do some manual configuration too. Read the release notes for beta22 before trying it out.

I see that with MariaDB. Small (really small) writes to the databases generates gigabytes of written data in no time.

I have tried that. Pointing to /mnt/cache/appdata or /mnt/user/appdata. Made no big difference. Just other names in iotop for the processes that eats away data. Edit shfs vs the real process name

I see the same regarding MariaDB. Lots of small writes to my databases but it generates huge amount of writes to the ssds. For now, I have my databases on one of my unassigned devices but that's not optimal. Just to save some ssd cache wear. I still see lots of writes to my cache from other dockers.

Just want to say that I used this script and it worked as expected. Thanks!

I add some trackers using the "Automatically add these trackers to new downloads" but that setting and field reset when restarting the container. In qBittorrent.conf: Bittorrent\AddTrackers=true Bittorrent\TrackersList=udp://tracker.example.com:669/announce\nudp://tracker2.example.com:699/announce After container restart Bittorrent\AddTrackers=false Bittorrent\TrackersList= Edit: This could of course be a problem with qbittorrent itself. hmm.

I would guess this container is missing the required dependencies to make the built in version work. Also guessing it has something to do with Alpine.

I see lots of data written but not only limited to the docker.img file and it's loopback device. It has something to do with the cache in some way. In my later answers in that thread, I talk about mariadb causing 12-20GB of written data every hour. That's extreme with my light use of nextcloud and home assistant (with mariadb as db). My databases are like 100MB in total. The 12-20GB/h just disappears in som black hole. It's a silent SSD killer.

Yes. I tried three different locations. /mnt/cache/appdata, /mnt/user/appdata (set to cache only) and /mnt/user/arraydata (array only). The two first locations generate that crazy 12-20GB/h. On array, it was like 10x+ less writing. The loop device also does some writing I find strange, yes. Wrote about this before noticing the high mariadb usage.. I will read your bug report and answers. Edit: this is just by keeping an eye on mariadb specifically. Other containers writing to the appdata dir will probably also generate lots of waste data including the loopback docker.img.

loop2 is the mounted docker.img, right? I have it pointed to /mnt/cache/system/docker/docker.img What did you change in your rc.docker?

Running MariaDB-docker pointed to /mnt/cache/appdata/mariadb or /mnt/user/appdata/mariadb (Use cache: Only) generates LOTS of writes to the cache drive(s). Between 15-20GB/h. iotop showing almost all that writing consumed by mariadb. Moving the databases to array, the writes goes down very much (using "iotop -ao"). I use MariaDB for light use of Nextcloud and Home Assistant. Nothing else. This is iotop for an hour with mariadb databases on cache drive. /mnt/cache/appdata or /mnt/user/appdata with cache only: When /mnt/cache/appdata is used, the shfs-processes will show as mysql(d?). Missing screenshot. This is iotop for about an hour with databases on array. /mnt/user/araydata: Still a bit much (seen to my light usage) but not even near the writing when on cache. I don't know if this is a bug in Unraid, btrfs or something but I will keep my databases on array to save some ssd life. I will loose speed but as I said, this is with very light use of mariadb.. I checked tree different ways to enter the path to the location for databases (/config) and let it sit for an hour with freshly started iotop between the different paths. To calculate data used, I checked and compared the smart value "233 Lifetime wts to flsh GB" for the ssd(s). Running mirrored drives. I guess other stuff writing to the cache drive or share with cache set to only will have unnecessary high writes. Sorry for my rumble. I get like that when I'm interested in a specific area. Not native english speaker. Please, just ask if unclear. Edit: My docs On /mnt/cache/appdata/mariadb (direct cache drive) 2020-02-08 kl 22:02 - 23:04. 15 (!) GB written. On /mnt/user/arraydata/mariadb (user share on array only) 2020-02-08 kl 23:04-00:02. 2 GB written. On /mnt/user/appdata/mariadb (Use cache: Only) 2020-02-09 kl 00:02-01:02. 22 GB (!) written. Just ran this again to really see the differense and loook attt itttt. On /mnt/user/arraydata/mariadb (array only, spinning rust) 2020-02-09 kl 01:02-02:02. 4 GB written.

Change both PUID and PGID to 0 in the settings for the container.