June 24, 201412 yr Hey there, this morning I woke up and got a red ball on one of my drives. I then tried to obtain the SMART report and it said 'no such device' which leads me to believe that the cable disconnected. Here is the syslog: http://pastebin.com/7yNXJYNM Then I did this: Disable AutoStart of Array Shut Down Reconnect Cables of that HDD Power Up SMART test the drive. the logs are attached. Could you please tell me if the drive is okay? If I decide to reuse the drive. I get that the standard procedure is to clear it and start the rebuild process. WHAT IF for some reason i don't trust my parity (i know I am a horrible person and did not check it ), I thought I could mount the disabled drive, copy its content and then start the rebuild process. I would then have a backup if the parity was corrupted. As it turned out, the filesystem was damaged, I ran reiserfsck /dev/md3 and got this: 1 found corruptions can be fixed only when running with --rebuild-tree Now the question: Can I use --rebuild tree without unRAID writing to the parity? Thank you very much, any help is greatly appreciated! smart_old.txt smart_short.txt smart_long.txt
June 25, 201412 yr Author Can anybody help me to explain this problem? What does the syslog tell, are the SMART logs ok?
July 1, 201412 yr syslog Line #1684 = Jun 23 15:35:04 Server kernel: ata4.00: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen http://lime-technology.com/wiki/index.php?title=The_Analysis_of_Drive_Issues#Drive_interface_issue_.233 This is transmission error. Most common causes are power related or unreliable connection especially if backplanes are involved. Is the problem still reproducible? If so, can you please try to move it to different power connector and SATA port and see what changes? ATA4 is this disk, "ST3000DM001-1CH166"
July 2, 201412 yr Author Thank you for your answer! I changed the ATA position and switched power connectors. But how can I check if the drive is okay, if it is disabled? During the filesystem check I had no errors, I remember. Do you think I can trust the data on the drive? (Except for the last file the mover tried) In this case I would rebuild parity. The problem with the corrupted filesystem still exists in this case. Can I use rebuild-tree without writing to the parity? (Would be no problem if I can be sure that the data on the drive is ok) edit: Could fixing the filesystem without writing to the parity maybe be reiserfsck --rebuild-tree /dev/sde1 ?
Archived
This topic is now archived and is closed to further replies.