Jump to content

nas_nerd

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About nas_nerd

  • Rank
    Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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!
  4. Thanks, my SSD smart attributes doesn't show the data written like some users above have posted screen caps of.
  5. 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.
  6. 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.
  7. 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".
  8. 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.
  9. 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.
  10. 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?
  11. Error is gone now, thank you Squid.
  12. Hi, I just got his error after being prompted to update to the latest version of CA whilst I was in the Auto Update Applications settings menu. A banner popped up at the top the screen prompting me to update CA to latest version - I clicked update - updated successfully - now I get this error each time I go to the Auto Update Applications setting. unraid-diagnostics-20200406-0632.zip
  13. My fav is the community support and developers. For 2020? I think an internal file browser would be very helpful. Cheers