DaveDoesStuff

Members
  • Posts

    55
  • Joined

  • Last visited

Recent Profile Visitors

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

DaveDoesStuff's Achievements

Rookie

Rookie (2/14)

3

Reputation

  1. Ok so I managed a parity check a few days ago but I wanted to wait until it had been up and running for a least a week. As of Friday it has been. During this whole time I have had the nVidia plugin disabled/removed and now there are no crashes, USBs getting corrupted, other errors etc... Also as my issues started after moving to 6.9 RC1 I definitely think the issues I've experianced since have to have been related to nVidia plugin or the change in how unRaid works with the driver. None of these issues were happening when the driver/support was still baked into the OS natively.
  2. Presumabely no. I'm trying another parity check now that work is finished for the week. My unRAID is host to my pfSense router with a dedicated dual nic so I didn't want to risk doing anything mid week. Will post back if it completes...but I've changed literally nothing...except I've disabled nVidia plugin as there were a ton of errors in my logs related to it.
  3. Yeah I had roughly the same thing happen with the first USB that "went bad", I just restarted to change some fan profiles and then it was suddenly f'ed. That was after the same usb3.0 stick and usb 3.0 port being fine for over a year prior to 6.9.X
  4. Hmm, did you have any usb issues lately also? I've burned two flash drives since 6.9.1/6.9.2 and had many system lockups etc... What other issues have you been having? Maybe something will jump out at me!
  5. USB has been replaced with help from support on the licence. However after I left a parity check running overnight I awoke to a dead network (I run virtual pfsense and a dedicated dual nic) and the lovely kernal panic attached. Powering off and on brought it back up and for now I'm running minimal dockers/vms and stopped the auto parity check. It's probably just my paranoia now but I can't help but feel like this isn't a coincidence... Edit: forgot to add I will endeavour to capture and attach diagnostics when I am back home
  6. Thats definitely on the cards but only when the spare/replacement flash drives arrive. It's not an option now as the last time I had these syptoms the drive was dead after restart. ...I mean what are the odds of both drives dying/having these issues within a 2 month period, seems slim...but maybe I'm over thinking this.
  7. Howdy folks, As the subject says I have a second USB drive failing in two months. Last time it happened I didn't catch what was happening until after the drive (Kingston Datatraveller USB3.0) had completely failed and unraid wouldn't boot after a restart I was going for unrelated reasons. Hours of worry, a new USB (same model/brand/spec) and licence transfer later it was fixed. Now 2 months later I got a notification via telegram to say that fix common problems detected a problem with bread errors etc...and low and behold it looks like the issue is happening again. It should be mentioned that a few weeks back I had taken my server offline to change some BIOS fan settings and on first restart the USB failed and I had to plug it into another PC, repair it and try again (it worked). This time around the port the failing USB is in is different, not even close to the previous one on the motherboard rear IO. I've ordered some new USB2.0 Datatravellers and emailed limetech about re-assiging my licence again within the 12 month time limit. However I'm concerend I'll be right back where I am in a short while. I'm also concerned that as soon as I restart I will be unable to boot again with the current device. Which would be in keeping with what happened the last time around, are there any "in-place" actions I can take to repair the current drive without a restart? Or to at least confirm it is screwed? (and ideally why). Obviously I've gone over my logs etc but I'm not sure what I should be looking for here, any steer in the right direction would be appreciated. Additional Info: Motherboard: TUF B450-PLUS GAMING BIOS: Version 3002 (AMD AGESA 1.2.0.1) USB Port: USB 2.0 (Port 11 bottom, according to the diagram in the user manual) CPU/RAM/GPU/PSU Ryzen 2700X @3.7gHz stock 32GB RAM (4x Team Group Vulcan Z T-Force 8GB DDR4 3000MHz) Silverstone Essential 550W 80 Plus Gold nVidia Geforce GT710 1GB USB: Kingston Datatraveller USB3.0 Can't find a link to the particular one I have anywhere (guess they are out of production) but it looks like the below (ignore the model number): ibstorage-diagnostics-20210531-1126.zip
  8. Fair enough, i'll try to over engineer something to achieve the same thing! Thanks again.
  9. Hmm, didn't know that. To be fair it would be counter-intuitive for me to assume it's a load of crap lol but thank you for the info. So obviously there *was* an issue that lead to these two devices racking up 58.5TB in writes in just 4 months since I began using them...and it seems like possibly something I did either earlier or in the last 72 hours has actually fixed it but I was focusing on metrics that don't actually represent the TBW or possibly even misrepresent it. Now I'll just have to re-enable Qbtorrent and monitor it closely, then if that checks out Duplicati (which I feel is possibly the culprit) and take some additional actions depending on the outcome. Thank you for the fresh set of eyes on this Jorge! I had complete tunnel vision until you came along lol! Do you use any particular tools or commands on your own setup(s) to monitor this kind of thing? Or anything you would recommend over what I've utilised in this thread?
  10. So after running overnight... Cache 1: 114,313,326 [58.5 TB] Cache 2: 114,312,943 [58.5 TB] Thats a delta of roughly 35,000 on each drive. No this does not seem like a lot...but unRAID main reporting 3.9 million when it was around 2.6 million yesterday evening is still pretty bad so a server that was essentially only running a handful of low IO dockers and a pfSense VM.
  11. I believe what I posted is actually for the total time this "server" has been in operation/powered on. That's probably a bit useless come to think of it, I picked it up in a bug report Currently the 2 cache drives report: Cache 1: 114,276,540 [58.5 TB] Cache 2: 114,276,147 [58.5 TB]
  12. Yeah for sure its not adding up. I've got Qbtorrent disabled now, at time of writing this the TBW is: Let's see where it sits tomorrow morning. Thank you for the assit by the way!
  13. Nothing beyond the standard Radarr/Sonarr > Qbtorrent > Plex setup used by many. Here is a screenshot of QB at present along with a fresh iotop, the QB screenshot effectively represents my last 72 hours of torrenting. As you can see, not a ton. From what I've seen on the forums here I'd say it's a standard amount even. EDIT: I've just noticed that iotop, despite being the same window running for the last 6 hours seems to be giving inconsistant stats...haven't used it outside of troubleshooting this issue so not sure if thats normal. For example in the screenshot in this post taken at roughly 6hrs run time, compared to the previous 4hrs one the entries at the top for highest write are missing. EDIT2: Added share settings to the OP.
  14. That's what I've been thinking...but not sure how to narrow it down further, or possibly go beyound whatever bounds iotop has. Here is an SS from 4 hours, not much difference.