Jump to content

JorgeB

Moderators
  • Posts

    67,412
  • Joined

  • Last visited

  • Days Won

    705

Everything posted by JorgeB

  1. Since the cache never mounted it should have no direct relation to that, I did notice this segfault in the end of the syslog: Mar 18 03:40:01 Tower kernel: shfs[3677]: segfault at 0 ip 0000000000403bd6 sp 00001511c7ea5930 error 4 in shfs[403000+c000] Mar 18 03:40:01 Tower kernel: Code: 89 7d f8 48 89 75 f0 eb 1d 48 8b 55 f0 48 8d 42 01 48 89 45 f0 48 8b 45 f8 48 8d 48 01 48 89 4d f8 0f b6 12 88 10 48 8b 45 f0 <0f> b6 00 84 c0 74 0b 48 8b 45 f0 0f b6 00 3c 2f 75 cd 48 8b 45 f8 This was most likely what cause /mnt/user to go away, but no idea what caused the segfault itself, could be hardware issue or some plugin, if it keeps happening good to run memtest and/or boot in safe mode.
  2. Yes. The disk that got disable (disk7) will stay disable, you'll need to either rebuild on top (only if the emulated disk mounts correctly) or do a new config and run a correcting parity check. Before doing anything you should also check SMART for the disks that dropped (6 and 7), they should be OK but better check before doing anything, if you want post diags so we can also check.
  3. Yep, updating the BIOS firmware should fix it. Should be possible, boot with a DOS flash drive.
  4. Please post diags, LSI might need a firmware update.
  5. You need to format them, next to array stop/start. You need to post the diagnostics (tools -> diagnostics) for the other issues.
  6. Yes, both the SASLP and SAS2LP are nothing but trouble with recent Unraid, look for any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed.
  7. Disk5 and parity need a new SATA cable. The read errors appear to be the typical SASLP problem, multiple disks dropped offline at the same time, recommend replacing it with an LSI.
  8. You you started the array with the missing pool device did the cache mount?
  9. Ideally 24H, but usually a few minutes/hours are enough for any serious problem to be found.
  10. There are multiple call traces, and if it still crashes with same Unraid release it was working before then they are likely hardware related, start by running memtest.
  11. Then it's likely a hardware problem.
  12. Downgrade back to last Unraid release that was stable for you to confirm if it was upgrade related or not.
  13. Did you format the cache? It doesn't have a valid filesystem, like it was never formatted.
  14. No valid filesystem is being detected on cache, like it was never formatted, that or it was wiped.
  15. Everything looks normal on the diags posted, there aren't any disk errors.
  16. Cancel the rebuild, update firmware, start rebuild again and see if the read errors go away.
  17. Yes to all, risk is low but there's always a risk, just make sure cache backups are up do date.
  18. Likely related to the same issue, do the firmware upgrade first and see how it goes, BTW no point in rebuilding a disk with multiple disk errors.
  19. Always, but they weren't reported before, the attribute wasn't monitored.
  20. Mar 18 13:03:31 Tower kernel: mpt2sas_cm0: LSISAS2008: FWVersion(20.00.00.00), ChipRevision(0x03), BiosVersion(07.39.00.00) Update the LSI firmware to 20.00.07.00, it's a known issues with that one.
  21. There's always some overhead on transfers, normal to get a little less than iperf on real world, most important IMHO are the lowish iperf results, when all is optimal you should get close to line speed on iperf.
  22. There were read errors on the cache device: Mar 18 12:32:02 NAS1 kernel: sd 12:0:7:0: [sds] tag#511 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Mar 18 12:32:02 NAS1 kernel: sd 12:0:7:0: [sds] tag#511 Sense Key : 0x2 [current] Mar 18 12:32:02 NAS1 kernel: sd 12:0:7:0: [sds] tag#511 ASC=0x4 ASCQ=0x0 Mar 18 12:32:02 NAS1 kernel: sd 12:0:7:0: [sds] tag#511 CDB: opcode=0x28 28 00 2b 30 01 28 00 00 08 00 Mar 18 12:32:02 NAS1 kernel: print_req_error: I/O error, dev sds, sector 724566312 Mar 18 12:32:02 NAS1 kernel: XFS (sds1): xfs_do_force_shutdown(0x2) called from line 1271 of file fs/xfs/xfs_log.c. Return address = 000000009734983c Mar 18 12:32:02 NAS1 kernel: XFS (sds1): Log I/O Error Detected. Shutting down filesystem Mar 18 12:32:02 NAS1 kernel: XFS (sds1): Please umount the filesystem and rectify the problem(s) Start by replacing cables. P.S. there were also read errors on disk3, do you have system notifications enable?
  23. Yeah, not sure it was a bug or not implemented, thanks for the update.
×
×
  • Create New...