• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About nas_nerd

  • Rank


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Any update on this? Same problem here .....
  2. Hi all, Firstly thanks for all the great work with this plugin. I am setting up spare SSD for my Plex appdata as an unassigned disk rather than through the cache drive appdata. What is the lightning bolt symbol next to the drive name? I don't think I have seen this until recently....? Just want to ensure it is setup correctly before transferring all the Plex data.
  3. Ah ok then. Maybe that is a standard thing for Intel 1151 sockets. The image I attached is actually the mini-itx version of what you have.
  4. Hi Hoopster, I am referring to a metal backplate on the underside of the mobo. Some motherboards come with them to support the CPU bracket thing on the top side. I was worried it would interfere with the noctua mounting system.
  5. Hi all, I am looking into this asrock mobo. Can anyone comment if there is a backplate on the rear of the mobo that would interfere with Noctua heatsinks, something like the NH-U9S or NH-D9L? I read about issues with the X470 AMD micro atx Asrock version... So much good info here, thanks!
  6. Thanks, my SSD smart attributes doesn't show the data written like some users above have posted screen caps of.
  7. Make sure you have libffi installed and updated to get iotop to work. I'm sure limetech are aware of this issue, they are no doubt busy on 6.9 at the moment, hopefully after it is released they can turn their focus to this issue.
  8. Bad news on my end, my writes have crept back up again, and arguably just as bad as it was before I switched my cache to XFS. This suggests it is a docker issue again. I need to do more testing but at this stage I am suspecting the Nextcloud/MariaDB dockers are causing the excessive writes. I would be interested if other people are using these dockers and can test by stopping them and tracking writes? I need to back-track from blaming BTRFS now too, at least in my case, the file system does not appear to be a factor in excessive writes.
  9. Update from my end: Converted my 500GB SSD BTRFS cache pool to a single XFS 500GB cache. Writes to the cache have now dropped significantly. I am running the exact same dockers as previously. This suggests a BTRFS + Docker combination is contributing to this excessive write problem. Unfortunately now my cache is unprotected and I have a spare 500gb SSD (I'm sure I'll find a use for this :)) I agree with a few comments about this issue/bug being more significant than "minor".
  10. Another update. I stopped all my docker containers overnight (but docker was still enabled), and I barely had any writes to the cache. This to me suggests potentially a rogue docker application, or having dockers running is causing an issue. More testing is required on my behalf.
  11. I suspect I am also experiencing this issue. The iotop screenshot is from a 2 hour period where the server was idling for most of the time. ~11GB from loop2 in 2 hours.... 2 Samsung 500gb Evo SSD in BTRFS pool, no encryption. ****update**** 8 hours later it looks like almost 900gb in writes? I hope I am interpreting this incorrectly? I need to fix this ASAP otherwise these SSDs will be cooked by the end of the month.
  12. Hi all, I would like to move my current SABnzdb (Linuxserver) over to this VPN version, when setting up the template for binhex SABnzdbVPN can I simply change the appdata directory to the old linuxserver appdata and keep my current config etc?