Jump to content

johnnie.black

Members
  • Content Count

    17421
  • Joined

  • Last visited

  • Days Won

    210

Everything posted by johnnie.black

  1. Because syslog is spammed with a repeating error I had missed there's a checksum error, likely on the metadata or the fs shouldn't go read only, if the disk was formatted recently with DUP metadata maybe it would be fixable, but doesn’t look like it so best bet it to backup, re-format and restore the data. Should still disconnect or wipe the unassigned disk mentioned above.
  2. A full disk write can sometimes fix the problem, but looking at the SMART report I would recommend replacing it.
  3. Don't known if it's related but the unassigned WDC_WD60EZRX-00MVLB1_WD-WX11D741AJNX has the same UUID as another disk, disconnect or clear/re-format that disk.
  4. IT mode is Initiator Target mode, no RAID, if it's a genuine LSI 9300-8i it should already be in IT mode, you can check during boot if there's a bios installed, alternatively post the diagnostics with the HBA installed.
  5. Are you using the Ryzen workarounds? https://forums.unraid.net/topic/80006-random-crashes-restarts/?do=findComment&comment=742911
  6. Don't know, but they aren't recommended anyway, SAS2 and newer LSI HBAs do support them, and those are recommended.
  7. You're leaving some info out or something else is going on, rebuilt disk and emulated disk should have exactly the same contents. Start another rebuild and the disk should mount immediately, if it doesn't post new diags.
  8. No, either parity was out of sync or filesystem got corrupted when it switched to the emulated disk, small corruption when Unraid disables a disk and switches to the emulated one has been known to happen in some cases. You'll need to try and recover the data using the old disk and/or the btrfs recovery tools linked above, then format it.
  9. There isn't a warning for filesystem corruption, only by looking at the syslog, though for more severe cases the disk will be unmountable and that can be seen on the GUI.
  10. CRC errors are a communication issue. most times a bad SATA cable, much less likely it can also be the enclosure or controller.
  11. Transaction ID is way off, a small difference can happen for example after an unclean shutdown, something very wrong happened there to have such a large difference, in any case that error is fatal, you can see here for some possible options to recover the data.
  12. Disk1 is failing but since you don't have parity you can't do a standard replacement. You can try ddrescue.
  13. Check filesystem on disk2: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui
  14. Yes. No, but make sure HBA is using IT mode. Set to cache "Yes" then run the mover. P.S: LSI requires SSDs with read zero after trim or trim won't work.
  15. Unusual 3 disks going unmountable ate the same time, any recent hardware/software change? In any case you'll need to check filesystem on all of them: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui P.S. Since you didn't mentioned it parity is disable.
  16. Those are checksum errors, most commonly caused by bad RAM or similar hardware problem, very unlikely to be a problem with the SSD.
  17. That's what I would do, since it's not the first time there are read errors.
  18. It was a disk problem, though it might be an intermittent error, it could be OK for some time, it could fail again next week, difficult to predict, it passed the extend test but it failed in the past. P.S. The cache SSD desperately needs a new SATA cable.
  19. Since current pool has uncorrectable errors, backup cache, re-format and restore the data, if it goes read-only again after a few days very likely there are still hardware problems.