devanchya

You sent me down a rabbit hole. Looks like it would take a month for a card to get to me. Anything I can do for safety now? Doesn't seem that anyone in Toronto sells these off the shelf anymore...

I haven't used LSI SAS to Sata before, anything I need to know. A manual or read-up will do.

@johnnie.black can you suggest a replacement. I got these from someone else recommending them and obviously lost the bet.

thanks @itimpi , I have replaced all the SATA cables already, and moved to a different port as well.

I've attached the diagnostics. I haven't found anything obvious in them, but obviously I wouldn't be here if I could see it tower-diagnostics-20190802-1415.zip

I've been having issues with my unraid and I can't track down the cause of it. The ATA is being dropped with a hard reset, and coming back up at a lower level. These are 6 Gbps connections, and the first drop go down to 3 Gbps and then later 1.5 Gbps. I've changed sata cables, power supply, SATA controllers, motherboard, even different drives and this keeps occuring. I'm at a loss what could be causing this. It occurs during rebuilding of Parity and Plex streaming. I'm out of ideas what could be causing it. Any suggestions GREATLY appreciated. Aug 2 05:03:38 Tower kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Aug 2 05:03:38 Tower kernel: ata7.00: failed command: WRITE DMA EXT Aug 2 05:03:38 Tower kernel: ata7.00: cmd 35/00:08:88:ce:3f/00:00:7f:00:00/e0 tag 12 dma 4096 out Aug 2 05:03:38 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Aug 2 05:03:38 Tower kernel: ata7.00: status: { DRDY } Aug 2 05:03:38 Tower kernel: ata7: hard resetting link Aug 2 05:03:39 Tower kernel: ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Aug 2 05:03:39 Tower kernel: ata7.00: configured for UDMA/33 Aug 2 05:03:39 Tower kernel: ata7: EH complete

Thank you it was Disk 2 that was damaged in the XFS. It's a new drive so I'm doing extra checks on it.

I'm having an issue where MOVER is making my /mnt/user*/ go read only. It appears to be due to a Metadata CRC error, but I can't tell where. There is no log saying which drive this is occurring on. All my drives appear GREEN in UnRaid. All Smart data looks good. I'm stumped. Jun 13 11:40:14 Tower kernel: XFS (md2): Metadata CRC error detected at xfs_allocbt_read_verify+0xd/0x3a [xfs], xfs_allocbt block 0x3a382228 Jun 13 11:40:14 Tower kernel: XFS (md2): Unmount and run xfs_repair Jun 13 11:40:14 Tower kernel: XFS (md2): First 128 bytes of corrupted metadata buffer: Jun 13 11:40:14 Tower kernel: 000000000dbd6522: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000eedb3762: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000d06bd14d: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000dae76d5c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000cf714964: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 000000001f761a42: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000ba3c7088: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 0000000068f2624d: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x3a382228 len 8 error 74

When I check /mnt/cache it shows 600gb in my one directory that should have been moved to other drives however when I run /usr/local/sbin/mover it immediately states it is finished running. This is for 6.2 RC4 Logs show no text output other than "mover finished" The "Cache" option had been turned off. Fixing the settings in the share worked

thanks john. Its worth a shot.

One of the ports on my main machine appears to have gone bad. It's a long story but the ESata would connect to the 4 drive bay properly, but after about 15 minutes the drives would spin down and I could not spin them back up. Added to the join I discovered this issue halfway through a parity check which stopped at 33% ... so my Parity drive may be full of bad data. I've replaced the cable, same issue. Tried another cable and it wouldn't even see the enclosure. Tried another enclosure, same issue as first enclosure. I decided to see if USB worked, and being UNRAID I was sure it wouldn't... and was surprised that Unraid 6.2RC appears to support USB (I've been around a long time, so forgive me for missing this... 4.7 days) However USB changed the ID of the drives by adding some USB Specific code to the drive Serial name. I've manually mounted the drives and confirmed they are in the proper spots. It helped they were 2TB, 3TB, and 4TB so could tell by size as well. However I'm stuck with the To many missing or incorrect disks cfg error. Is there anyway to fix this so I can try to see if Partiy will restore (did I forget to mention?) the one drive that had died.

I currently have a large set of data of similar types. TV Shows etc. Some of the shows are split across 20+ drives. I would like to consolidate some of the data to same drives prior to migrating the drives to larger capacity. Is there any way to automatically get all of X show to Drive 3 for example.

The drives were mis-labeled for type, and it appears a a single ext-sata cord was loose from some long term vibration.

attaching diagnostics tower-diagnostics-20160712-0609.zip

6.1.9, unraid. I have 10 drives showing mountable, 10 drives suddenly showing not mountable. I had 1 drive show up bad yesterday so I rebooted the box to check if it was a false positive until I could get a replacement. Machine came up. BIOS missing, had to rebuild using backup bios. UnRaid comes up, all the drive configurations are missing. I bring up the drives (with no parity) and confirm that 10 are working properly, the other 10 are showing unmountable Whats the best way to confirm the other drives are still good? I was thinking of manually mounting them in /mnt temporarly. I'm still trying to figure out a cause. the 10 drives that are down may be connected via an external SATA card so it could be a case of the BIOS not loading the card right after a reset, still checking. Jul 11 19:42:14 Tower kernel: REISERFS warning (device md1): sh-2011 read_super_block: can't find a reiserfs filesystem on (dev md1, block 16, size 4096) Jul 11 19:42:14 Tower kernel: REISERFS warning (device md1): sh-2021 reiserfs_fill_super: can not find reiserfs on md1 Jul 11 19:42:14 Tower emhttp: shcmd: shcmd (48): exit status: 32 Jul 11 19:42:14 Tower emhttp: mount error: No file system (32) Jul 11 19:42:14 Tower emhttp: shcmd (49): rmdir /mnt/disk1 Jul 11 19:42:14 Tower emhttp: shcmd (50): mkdir -p /mnt/disk2 Jul 11 19:42:14 Tower emhttp: shcmd (51): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jul 11 19:42:14 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Jul 11 19:42:14 Tower kernel: REISERFS (device md2): using ordered data mode Jul 11 19:42:14 Tower kernel: reiserfs: using flush barriers Jul 11 19:42:14 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jul 11 19:42:14 Tower kernel: REISERFS (device md2): checking transaction log (md2) Jul 11 19:42:14 Tower kernel: REISERFS (device md2): Using r5 hash to sort names Jul 11 19:42:15 Tower emhttp: shcmd (52): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jul 11 19:42:15 Tower emhttp: reiserfs: resizing /mnt/disk2 Jul 11 19:42:15 Tower emhttp: shcmd (53): mkdir -p /mnt/disk3 Jul 11 19:42:15 Tower emhttp: shcmd (54): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Jul 11 19:42:15 Tower kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Jul 11 19:42:15 Tower kernel: REISERFS (device md3): using ordered data mode Jul 11 19:42:15 Tower kernel: reiserfs: using flush barriers Jul 11 19:42:15 Tower kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jul 11 19:42:15 Tower kernel: REISERFS (device md3): checking transaction log (md3) Jul 11 19:42:15 Tower kernel: REISERFS (device md3): Using r5 hash to sort names Jul 11 19:42:15 Tower emhttp: shcmd (55): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Jul 11 19:42:15 Tower emhttp: reiserfs: resizing /mnt/disk3 Jul 11 19:42:15 Tower emhttp: shcmd (56): mkdir -p /mnt/disk4 Jul 11 19:42:15 Tower emhttp: shcmd (57): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md4 /mnt/disk4 |& logger Jul 11 19:42:15 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md4, Jul 11 19:42:15 Tower logger: missing codepage or helper program, or other error Jul 11 19:42:15 Tower logger: In some cases useful info is found in syslog - try Jul 11 19:42:15 Tower logger: dmesg | tail or so Jul 11 19:42:15 Tower logger: Jul 11 19:42:15 Tower emhttp: shcmd: shcmd (57): exit status: 32 Jul 11 19:42:15 Tower emhttp: mount error: No file system (32) Jul 11 19:42:15 Tower emhttp: shcmd (58): rmdir /mnt/disk4 Jul 11 19:42:15 Tower kernel: REISERFS warning (device md4): sh-2021 reiserfs_fill_super: can not find reiserfs on md4 Jul 11 19:42:15 Tower emhttp: shcmd (59): mkdir -p /mnt/disk5 Jul 11 19:42:15 Tower emhttp: shcmd (60): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md5 /mnt/disk5 |& logger Jul 11 19:42:15 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md5, Jul 11 19:42:15 Tower logger: missing codepage or helper program, or other error Jul 11 19:42:15 Tower logger: In some cases useful info is found in syslog - try Jul 11 19:42:15 Tower logger: dmesg | tail or so