Jump to content

atconc

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About atconc

  • Rank
    Newbie
  1. I've been running unraid on this hardware for a few years and it's been mostly rock solid but recently I've been getting some lockups where the system becomes completely unresponsive (stops responding to ping, ssh sessions die, apps in docker containers stop working). I haven't noticed a particular pattern for when these crashes occur, to have idea whether this is load related for example, timingwise I think this corresponds with upgrading to 6.8.0. I turned on the syslog writing to usb feature and caught the logs which i have attached (edited to redact my email address from notifications but otherwise untouched). I just saw 6.8.1 is out with some kernel updates so have upgraded to see if things improve but in the meantime thought I'd also post here with the syslog. There's a couple of "kernel bug error" lines and lots like: rcu_sched self-detected stall on CPU Hardware is: Gigabyte Z97-D3H-CF motherboard 32gb DDR3 ram CPU Xeon e3-1230 LSI SAS controller Array drives 4x 8tb wd red , 6 x 3tb wd red - single parity with one of the 8tb reds Cache 2x 480gb sandisk ssds 2 other drives unassigned (2tb wd green and 128gb crucial ssd used as scratch drives) I'm running various apps in docker: Plex, sonarr, radarr, nzbget, unifi controller etc Everything is running headless but I do have a graphics card arrived today so I can check bios settings etc if this persists. syslog-email-removed.log
  2. I'd rather not give up that much capacity if possible, so being able to enable trim, with my eyes open to the security impact would be good.
  3. Is there any further update on adding this as a setting? or a guide somewhere on how to manually update the necessary configs? My disk encryption use case is mostly just a first line of defense against physical theft of my unraid box. This is just a home install so the most sensitive data is stuff like tax returns and medical bills. So If a theft were to happen then my personal data is relatively safe from someone just booting the machine, or pulling the drive and trying to extract the contents. If my drive is in the hands of someone sophisticated and determined enough to try to exploit the gaps left by using TRIM on an encrypted drive then they probably have easier ways to get that data anyway... With that in mind I'd prefer to have the performance and durability benefits of TRIM over the additional security. I understand that in other use cases the security is the most critical thing but I would imagine those users are more likely to roll their own solution than take something off the shelf.