February 21, 20179 yr Gang, Unraid 6.2.4. Upgraded a 3TB parity disk to an 8TB parity disk. The parity-rebuild was at about 0.5% and humming along, and I went to work. Came home to an orange triangle (parity drive) and "Parity Invalid" as well as a red "X" and "disk unavailable" on Disk 1. syslog (now gone, of course, due to my haste) indicated several thousand lines of i/o errors on disk 1. All shares were unavailable. I rebooted. Disk 1 came up as 'unmountable', but the system auto-initiated a parity-sync and I wasn't sure if I should stop it or not. So I let it go.... This is what it said: -- Last check completed on Mon 20 Feb 2017 04:31:45 AM MST (today), finding 1953505933 errors. Duration: 21 minutes, 8 seconds. Average speed: 6.3 GB/sec -- Not sure why it went so fast or had such a massive speed. I did some research and re-started the array in maintenence mode. Ran the XFS filesystem check with the '-n' option in the GUI. Didn't specifically report errors, but also didn't give me a hard and fast "passed." Have not run the same command with the commit changes option (yet?). Re-started the array, and disk 1 is still red-X'd, but I was able to browse it. I can see the files and open them. If this is an emulated disk (still not 100% sure on how that all works) then it *appears* as though all the data is intact. On another server, over the years, I've had numerous red-balled disks, and it was always either a loose cable or something that I could never pin down. Since I trusted parity in those cases, I usually stopped the array, removed the disk, started the array, stopped the array, re-added the disk, and parity re-built it and I was back to 100%. I am concerned that I only have partial parity, since I do not believe the parity rebuild completed 100%. I'm concerned what might happen if I try to replace the disk with a spare and let the array rebuild, or remove/re-add and rebuild. I have never had an orange triangle on a parity drive (although, after my 21 minute warp-speed parity sync from earlier, parity is now listed as "valid" although I do not trust it) At the moment I have enough free space on other disks for all of the data on disk 1. So I created an "old_disk_1" share and am now, from the command line, recursively copying all data from /mnt/disk1 to /mnt/user/old_disk_1 since it will make it easier, as unraid will distribute the data using high water and I won't have to worry about copying over individual folders based on size. Plus, assuming this operation is successful, I feel its a good test to isolate the aforementioned i/o errors (I have not yet opened the server to check for loose cables, broken backplane parts (Silverstone DS380), etc.) Advice on how to proceed welcome.
February 21, 20179 yr 1 hour ago, johnnie.black said: Is old parity disk intact? I'd assume NOT, since he has created the "old disk 1" share and copied a bunch of data to it.
February 21, 20179 yr Community Expert 3 minutes ago, garycase said: I'd assume NOT, since he has created the "old disk 1" share and copied a bunch of data to it. Yes, didn't read that far. Tucansan, I'd like to see the diagnostics but from what you posted your parity won't be completely in sync, if that's the case the emulated disk1 will have some or a lot of corrupt files, since you invalided parity your options are now limited, but maybe the disk went offline from a bad cable/connection and it can be re-enabled.
February 21, 20179 yr Author Diags attached, thanks guys. Old parity disk is not in-tact.... File copy operating is nearly done (2.1tb in just over 24 hrs) so I'm not 100% sure how to proceed from here. Any operation involving a parity rebuild wouldn't be prudent, would it? Given that parity is probably all messed up or incomplete? ffs2-diagnostics-20170221-0553.zip
February 21, 20179 yr Community Expert Let the copy finish, nothing to lose now. SMART report for disk1 is incomplete, try to get it manually and post the results: smartctl -a -A /dev/sdi
February 21, 20179 yr Author root@ffs2:/mnt/disk1# smartctl -a -A /dev/sdi smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.30-unRAID] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Green Device Model: WDC WD30EZRX-00DC0B0 Serial Number: WD-WMC1T0340829 LU WWN Device Id: 5 0014ee 0036ac774 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Tue Feb 21 06:08:16 2017 MST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 41) The self-test routine was interrupted by the host with a hard or soft reset. Total time to complete Offline data collection: (40380) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 405) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x70b5) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 2 3 Spin_Up_Time 0x0027 180 180 021 Pre-fail Always - 5958 4 Start_Stop_Count 0x0032 093 093 000 Old_age Always - 7670 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 054 054 000 Old_age Always - 33798 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 107 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 58 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 1161537 194 Temperature_Celsius 0x0022 123 107 000 Old_age Always - 27 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Interrupted (host reset) 90% 33773 - # 2 Short offline Completed without error 00% 33772 - # 3 Short offline Completed without error 00% 33772 - # 4 Short offline Completed without error 00% 22252 - # 5 Short offline Completed without error 00% 22237 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
February 21, 20179 yr Author A large amount of this data is backed up, however that backup is a few weeks old now. Not much new data has been added, but saving what I can would be ideal, as there is plenty on there that was not backed up. Thanks again to all.
February 21, 20179 yr Author One other quick question.... What is the probability of success with mounting Disk 1 in another linux system to examine its contents? Edited February 21, 20179 yr by tucansam
February 21, 20179 yr Community Expert 2 minutes ago, tucansam said: One other quick question.... How difficult would it be to pull the Disk 1, put it in another linux machine, and mount it to pull data off that way? Easy but it shouldn't be needed. SMART for disk1 looks fine, and since it's on a Marvell controller that would be my first guess of what went wrong, they are known for dropping disks. Since the copy is almost over let it finish, then do a new config, retain all assignments, and start array to begin parity sync, if there are more issues during the sync grab the diags before rebooting.
February 21, 20179 yr Author Fantastic, thank you. I will give this is shot as soon as the copy is complete and report back. Assuming it was the Marvell controller that dropped the disk, is this a potential indication of an impending controller failure, or simply a fact of life with this particular chipset? Should I move the disk to another channel on the controller? Time to look at a new controller perhaps?
February 21, 20179 yr Community Expert More like issues with kernel/drivers currently used on unRAID, some models are worse than others, and not all users are affected, but IMO they should be avoided if possible. Other things that can help is disabling VT-D (if not neede) and/or bios update.
February 22, 20179 yr Author New Config and parity sync complete. One problem... All shares are gone. In addition, when I try to add a share, let's say "software" -- the system says "Software share has been deleted" Another issue... Disk 1 is saying 2.25TB out of 3TB used, however there are no files on the disk (GUI). When I ssh into the server, I am getting i/o errors at the command line for "ls" for Disk 1. But it is green-balled in unraid..... Edited February 22, 20179 yr by tucansam
February 22, 20179 yr Author Thanks! ffs2-diagnostics-20170222-0437.zip root@ffs2:/boot/config/shares# ls /mnt /bin/ls: cannot access '/mnt/user': Input/output error /bin/ls: cannot access '/mnt/disk1': Input/output error disk1/ disk2/ disk3/ disk4/ disk5/ disk6/ disk7/ disks/ user/ root@ffs2:/boot/config/shares# Edited February 22, 20179 yr by tucansam
February 22, 20179 yr Community Expert syslog got full and is not complete, reboot and grab new diags
February 22, 20179 yr Author Diags coming shortly. But as soon as I stopped the array, disk 1 disappeared and says "no device"
February 22, 20179 yr Community Expert Just now, tucansam said: But as soon as I stopped the array, disk 1 disappeared and says "no device" I assume this is when you stopped the array but before rebooting? If so then that normally means the disk dropped offline for some reason. I would carefully check the SATA and power cables to the drive.
February 22, 20179 yr Author Rebooted and data is available, disk 1 is online, etc. Diags attached. I'm going to bed, will see how the server looks in the afternoon. If the disk is dropping over a period of time, that will be interesting. I'll check cables and such at that time. Thank you again for your help sir. ffs2-diagnostics-20170222-0503.zip
February 22, 20179 yr Community Expert There was a filesystem issue with disk1 but it appears it got fixed on mount: Feb 22 05:01:34 ffs2 kernel: XFS (md1): Mounting V5 Filesystem Feb 22 05:01:35 ffs2 kernel: XFS (md1): Starting recovery (logdev: internal) Feb 22 05:01:35 ffs2 kernel: XFS (md1): Ending recovery (logdev: internal) At the moment all looks fine, but post if there are more issues.
February 22, 20179 yr Author Will do, thanks again. This forum has saved my butt more times than I can count.
February 22, 20179 yr Here is my guess of what happened. You opened your server to add or swap in the new parity. In the process, you nudged a cable attached to another disk. Even a very gentle nudge can be enough to cause a marginal connection. Building parity generates a huge amount of activity and traffic across the data cable and eventually transactions started failing and generating errors and retry attempts. Eventually something happened and it couldn't recover which led to the drive being kicked from the array. It IS possible that the disk decided that was the moment to fail, but MUCH more likely that it is the cabling scenario I mentioned. Saying that is common here is an understatement. This type of thing is reported daily. Failed drives that generate these symptoms are beyond rare. I don't think I've ever seen one. Highly recommended to use locking cables to create secure connections. If locking is not supported, you want to use a cable that has friction when sliding on the L shaped SATA post. If the cable slides on too easily, it should be replaced. Also, if there is tension on the cable, it will eventually pull loose. Relieve that tension. Drive cages are also advised. With them you can avoid ever having to stick your fat fingers in the delicate wiring to swap a disk in and/or out. I similarly upsized my parity recently, and shuffling 5-6 disks. Took me just a couple minutes to do with my drive cages in place. No chance of interfering with the cables. All preclears and parity builds went smoothly. I am not some super system builder - I had lots of problems in my earlier builds. But learned my lesson with hard knocks and so I used locking cables (even forcing them on in some cases where they were not meant to be - but super high friction is just as good.) I could not find SAS to SATA cables with locking ends when I did the builld, so I was very careful that I had good friction on each plug into the cages. I have drive cages for every drive. I have not stuck my hand inside the server in years Dual parity is meant to protect you from a second drive failure, but if your cabling is bad it can help if you knock ONE cable loose. But it is easy to disturb more than one, and dual parity will just make things worse as two drives will drop and you'll believe you have the worst luck. You really want your cabling in order to avoid these situations altogether. Its not what dual parity is for.
February 24, 20179 yr Author Well, happened again. In the last 48 hours, I did the 'new config' and all was well. The array came up and the data on Disk 1 was in-tact. I ran a parity sync and that completed without issue. I then upgraded a disk (not Disk 1) and the rebuild went fine. After the rebuild, I initiated a parity check. It made it somewhere between 40-50% and then aborted. Disk 1 was red X'd again. I pulled diags before I rebooted (attached). I pulled the server and inspected the cage (DS380). The inside of the cage for that bay shows no sign of damage. I opened the server and there was no undue tension on any of the cables; my SATA cables are all locking cables. I replaced Disk 1's SATA cable anyway, thinking maybe a cable had simply gone bad. I booted the system and up and... Disk 1 is still red X'd. I pulled diags post-boot (attached). I am thinking perhaps its a problem with the Marvell controller, perhaps a port has gone bad? Unfortunately I have no spare four-channel controllers with which to test, so, depending on what you guys think. I may be ordering a new controller ASAP. Failing that, perhaps, despite passing SMART tests, its time to replace the disk? post_reboot_ffs2-diagnostics-20170224-0451.zip pre-reboot_ffs2-diagnostics-20170224-0436.zip Edited February 24, 20179 yr by tucansam
February 24, 20179 yr Community Expert The disk is fine, problem is the Marvell controller, can't say for sure if it's a bad controller or the typical Marvell issues, but suspect the latter. Although there were no errors during disk5 rebuild all 4 disks on the marvell were having timeout issues: Feb 23 01:20:01 ffs2 kernel: ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 23 01:20:01 ffs2 kernel: ata9.00: failed command: SMART Feb 23 01:20:01 ffs2 kernel: ata9.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 20 pio 512 in Feb 23 01:20:01 ffs2 kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Feb 23 01:20:01 ffs2 kernel: ata9.00: status: { DRDY } Feb 23 01:20:01 ffs2 kernel: ata9: hard resetting link Feb 23 01:20:01 ffs2 kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 23 01:20:01 ffs2 kernel: ata8.00: failed command: SMART Feb 23 01:20:01 ffs2 kernel: ata8.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 10 pio 512 in Feb 23 01:20:01 ffs2 kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Feb 23 01:20:01 ffs2 kernel: ata8.00: status: { DRDY } Feb 23 01:20:01 ffs2 kernel: ata8: hard resetting link Feb 23 01:20:01 ffs2 kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Feb 23 01:20:01 ffs2 kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Feb 23 01:20:01 ffs2 kernel: ata9.00: configured for UDMA/133 Feb 23 01:20:01 ffs2 kernel: ata9: EH complete Feb 23 01:20:01 ffs2 kernel: ata8.00: configured for UDMA/133 Feb 23 01:20:01 ffs2 kernel: ata8: EH complete Feb 23 01:43:52 ffs2 kernel: ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 23 01:43:52 ffs2 kernel: ata9.00: failed command: IDENTIFY DEVICE Feb 23 01:43:52 ffs2 kernel: ata9.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 11 pio 512 in Feb 23 01:43:52 ffs2 kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Feb 23 01:43:52 ffs2 kernel: ata9.00: status: { DRDY } Feb 23 01:43:52 ffs2 kernel: ata9: hard resetting link Feb 23 01:43:52 ffs2 kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 23 01:43:52 ffs2 kernel: ata7.00: failed command: IDENTIFY DEVICE Feb 23 01:43:52 ffs2 kernel: ata7.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 10 pio 512 in Feb 23 01:43:52 ffs2 kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Feb 23 01:43:52 ffs2 kernel: ata7.00: status: { DRDY } Feb 23 01:43:52 ffs2 kernel: ata7: hard resetting link Feb 23 01:43:52 ffs2 kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Feb 23 01:43:52 ffs2 kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Feb 23 01:43:52 ffs2 kernel: ata7.00: configured for UDMA/133 Feb 23 01:43:52 ffs2 kernel: ata7: EH complete Feb 23 01:43:52 ffs2 kernel: ata9.00: configured for UDMA/133 Feb 23 01:43:52 ffs2 kernel: ata9: EH complete Feb 23 02:07:44 ffs2 kernel: ata10.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Feb 23 02:07:44 ffs2 kernel: ata10.00: failed command: SMART Feb 23 02:07:44 ffs2 kernel: ata10.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 20 pio 512 in Feb 23 02:07:44 ffs2 kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Feb 23 02:07:44 ffs2 kernel: ata10.00: status: { DRDY } Feb 23 02:07:44 ffs2 kernel: ata10: hard resetting link Feb 23 02:07:44 ffs2 kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Feb 23 02:07:44 ffs2 kernel: ata10.00: configured for UDMA/133 Feb 23 02:07:44 ffs2 kernel: ata10: EH complete These errors continued on the parity sync, in all 4 disks until disk1 got disabled: Feb 24 02:14:11 ffs2 kernel: ata10: hard resetting link Feb 24 02:14:11 ffs2 kernel: ata10: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Feb 24 02:14:41 ffs2 kernel: ata10.00: qc timeout (cmd 0xec) Feb 24 02:14:41 ffs2 kernel: ata10.00: failed to IDENTIFY (I/O error, err_mask=0x4) Feb 24 02:14:41 ffs2 kernel: ata10.00: revalidation failed (errno=-5) Feb 24 02:14:41 ffs2 kernel: ata10.00: disabled If you haven't yet disable vt-d if not used and look for a bios update, if issues persist get a new non Marvell controller.
February 24, 20179 yr Author Thanks a lot man. I've got an SASLP-MV8 in another server, and am just going to pick up another for this machine. Buy once, cry once.
Archived
This topic is now archived and is closed to further replies.