Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Gizmotoy

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

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

  1. Oh man, what a silly mistake. That definitely resolved the issue. Too bad the folder picker doesn't work for that path or I would have found out immediately. Thanks for the suggestion, I'm all set!
  2. I was trying to figure out why my Docker container utilization was high, and after running du -h -d 1 / from every docker container console and finding nothing, I decided to enable log rotation for my Docker image. So I set "Enabled" to "No", turned on Advance Settings, Enabled Log Rotation, and then set the max size to 1 file at 100MB. When I try to apply the changes I get the following image. The hover over for the red directory is "please match the requested format". I did not change that directory at all, and the format is correct: the path is accurate, and it's where all the other containers are stored. I do run Docker from an Unassigned Devices volume since I don't use a cache disk, but this is the first issue I've ever had with the arrangement in the maybe 3-4 years I've had it like this. That disk is mounted and active. I can't even re-enable Docker now. Any suggestions?
  3. I inspected cables, and some affected drives are on SAS cables to the Dell H310, and some are on plain SATA cables to the motherboard. In total, 9 cables are affected of varying brands, ages, and types. Power could potentially be the culprit but I’m not sure how to figure that out short of just replacing the power supply. It’s an oversized Seasonic 80 Platinum, so not a cheap supply.
  4. So I replaced my AOC-SASLP-MV8 with the Dell H310 and run a parity check and all is fine. The WebUI responsiveness issues have resolved. That said, I'm still getting a bunch of those scsi task aborts from above. It looks like they're on both the Dell adapter as well as the built-in motherboard ports, so everything is affected. Are they safe to ignore? New diag attached. hyperion-diagnostics-20190610-2005.zip
  5. Couple developments here: As soon as the preclear finished, the system went back to normal without a reboot. Drives are all online and nominal, Docker functional, WebUI functional. I ordered a refurbished Dell H310 as a backup in case my MV8 is failing, but it'll take a few days to arrive.
  6. So I've had a disk or two fail with read errors in the past 2 months. I just recovered from a failure, and was preclearing my hot spare. I came home today and to check on it, and noticed it was almost done. However, while interacting with it, the Unraid WebUI became unresponsive. I can still SSH in, so I grabbed the diagnostics (attached), but it looks like both my main Unraid WebUI and all Docker WebUIs are unresponsive. If I try to access the WebUI, I get the error in the attached image. It looks like maybe the webserver itself is up, but Unraid is down. If I look through the logs, I see a bunch of this starting today: Jun 5 19:12:37 Hyperion kernel: sd 8:0:1:0: attempting task abort! scmd(000000009f4a675f) Jun 5 19:12:37 Hyperion kernel: sd 8:0:1:0: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jun 5 19:12:37 Hyperion kernel: scsi target8:0:1: handle(0x000b), sas_address(0x4433221102000000), phy(2) Jun 5 19:12:37 Hyperion kernel: scsi target8:0:1: enclosure logical id(0x5003048011f2a900), slot(1) Jun 5 19:12:38 Hyperion kernel: sd 8:0:1:0: task abort: SUCCESS scmd(000000009f4a675f) Jun 5 19:12:46 Hyperion kernel: sd 8:0:4:0: attempting task abort! scmd(0000000010ab0e43) Jun 5 19:12:46 Hyperion kernel: sd 8:0:4:0: [sdf] tag#0 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jun 5 19:12:46 Hyperion kernel: scsi target8:0:4: handle(0x0010), sas_address(0x4433221107000000), phy(7) Jun 5 19:12:46 Hyperion kernel: scsi target8:0:4: enclosure logical id(0x5003048011f2a900), slot(4) Jun 5 19:12:47 Hyperion kernel: sd 8:0:4:0: task abort: SUCCESS scmd(0000000010ab0e43) Jun 5 19:32:39 Hyperion kernel: sd 8:0:1:0: Power-on or device reset occurred Jun 5 19:32:39 Hyperion kernel: sd 8:0:4:0: Power-on or device reset occurred Jun 5 19:32:39 Hyperion rc.diskinfo[5829]: SIGHUP received, forcing refresh of disks info. Jun 5 19:32:39 Hyperion rc.diskinfo[5829]: SIGHUP ignored - already refreshing disk info. So it looks like something is up, but I'm not sure what. So I have two questions: Is there a way to cleanly shut down the array now that this has happened? and Are there any clues as to what's gone wrong? I noticed it might be an error with my SAS controller. It's an AOC-SASLP-MV8 that, while a Marvell chipset, I've never had trouble with before (but is 8 years old now). If so, is there a recommended drop-in replacement? Any suggestions appreciated. Thanks! hyperion-diagnostics-20190605-1959.zip
  7. Have you had any problems with your SAS2LP-MV8 on 6.7? I have the same card and am hesitant to upgrade given the other issues noted in this thread. I guess I should investigate if there's a well-reviewed LSI-based card that's a drop-in replacement. I don't really want to redo cabling if I don't have to, and my MV8 has been rock solid for over 8 years now.
  8. Hmm. That does work, but only if I don't need access to Unraid itself. That makes Plex work, but it then breaks Unraid's Main even if I then set up a custom location for that. There's many inter-dependancies. This is tricky.
  9. Has anyone been able to get this to work with Plex? I've gotten Grafana and a bunch of others working, but Plex just redirects back to my main Unraid page. I just use an invalid TLD locally without SSL. With a local DNS server as well, this traffic never goes outside my network. Unraid is on 8008, and Plex is on its usual 32400.
  10. I've tried everything at this point. Bridged/Host/Static network modes and every optional parameter in `speedtest-cli`. I installed it on my desktop machine on the same network, and it works there. It just won't work in this docker container, for whatever reason. It's not a measurement/reporting issue, either: stats from my network switch confirms that the throughput is actually very low upstream. There's a large upstream burst right at the start of the test, then nothing, resulting in a low Mbps reading. I'm not an expert, but it kind of seems like it's waiting for acknowledgement from the Speedtest server before sending more data, and that ACK never arrives. The current results use HTTP. There's a pull request outstanding for a socket-based option. Maybe that'll help whenever it gets integrated back into master.
  11. This is great, thank you. The downstream measurements are now roughly inline with expectations. Still can't figure out why the upstream is locked to 4Mbps, though, but at least the downstream works.
  12. Thanks for the insight. I'm not super-knowledgable on underlying Docker stuff: can I just change the "Repository" field in my existing container? Or is it more complex than that?
  13. These are fantastic! Thanks! I'm using the Speedtestforinfluxdb and getting some unusual results, though. I have symmetrical gigabit fiber, and show Speedtests in the neighborhood of 800Mbps down, 4Mbps up. I could maybe believe the down (though it's about 940 Mbps when tested manually), but the upstream seems straight wrong (also 940Mbps when tested manually). I'm also seeing pings in the 25ms range ("0" to 2 ms is typical manually). Any thoughts on what might be wrong? I assume I've misconfigured something, but I'm not sure what. [GENERAL] Delay = 300 [INFLUXDB] Address = <my_actual_ip_was_here> Port = 8086 Database = speedtests Username = Password = Verify_SSL = False [SPEEDTEST] # Leave blank to auto pick server Server = [LOGGING] # Valid Options: critical, error, warning, info, debug Level = info
  14. Thanks. This seems to have worked until Crucial has a fix. Though I'm a bit worried they'll never fix it.
  15. Ah, I see. It's only available for array drives. This disk is mounted through Unassigned Devices, and it looks like drives not in the main array lack the ability to disable monitoring. Bummer. Maybe there's a workaround?