November 4, 201015 yr Hello, So I have been reading the forums and wiki over the past few months in preparation for building my own unRAID box. I'm currently coming from a Drobo with 2x 2TB and 2x 1.5TB WD Green EARS drives. My plan was to start copying over the files from the Drobo and ultimately repurpose the drives for unRAID. Then I was browsing this thread, http://lime-technology.com/forum/index.php?topic=8333.15 which was discussing some issues with the advanced format and unRAID (namely having used it unjumpered first then attempting to jumper the drive). I didn't want to hijack that thread, but I believe people were saying how once its been formatted without the jumper, you can't reapply the jumper and get any sort of reliability with unRAID. What I don't know for sure is, however, does that mean formatted with unRAID or with any type of format. Are my 4 Drobo drives not going to be able to be reliably used in unRAID since they are not new? Any advice anyone can offer is greatly appreciated! Thanks!
November 4, 201015 yr 1. Write zeros to the first several hundred sectors (250K of space) with dd, with the jumper off. 2. Put the jumper on, and do it again. 3. Preclear it with the jumper on 4. Then it is ready for use in unRAID.
November 4, 201015 yr Author Awesome. Thanks, bubbaQ. I was just browsing the Wiki on the matter and it lacks this info. I appreciate your response and am looking forward to starting my build soon!
November 8, 201015 yr Hi bubbaQ, could you please validate the dd command to achieve this? dd if=/dev/zero of=/dev/sdX bs=512 count=500 Is this OK? and another question: Joe L.'s pre-clear script is also starting with zeroing the entire disk, isn't it? If this is the case, then why others are reporting pre-clear failures after puting the jumper on? Shouldn't it has the same impact?
November 8, 201015 yr It's because the script preclear has a bug, that Joe L is working on fixing. it is because the drive stopped responding to commands until (apparently) it is power cycled. I'm going to fix the pre-clear script so it will recognize a drive that no longer responds when queried about its geometry. We still do not know if a drive that is not responding can be written to... My guess is that is cannot.... but I've been mistaken in the past. The next person who has a drive that is not responding... BEFORE power cycling, try this: dd if=/dev/zero of=/dev/sdX bs=512 count=2 Then we'll know if it can be written. Joe L.
November 8, 201015 yr I got confused about the ordering of the steps now. So what am I suppose to do to help you with the testing (without the risk of bricking the drive... )? 1. run the pre-clear script on the drive the jumper was put on 2. it will fail at some stage (not quite sure which stage?) 3. will the script abort and get back to the console? 4. run 'dd if=/dev/zero of=/dev/sdX bs=512 count=2' 5. re-run the script? But actually I've also got a little bit dubious with the issue: I have 3pcs wd 2tb ears drive installed and I forgot to put the jumper on on one of them. I am already using it for a couple of months without noticing any issue. I've just figured a day ago I forgot about the jumper. To be on the safe side I decided to do the migration, but while I am transferring the data directly from that disk I am copying with 80+MB/sec so there seems to be no performace issue, nor I experienced any reliability issues in the past months. Certainly I beleive you guys that the jumper should be on so no doubts about that, I am just wondering where should I notice/experience the issue?
November 9, 201015 yr but while I am transferring the data directly from that disk I am copying with 80+MB/sec so there seems to be no performace issue, nor I experienced any reliability issues in the past months. Certainly I beleive you guys that the jumper should be on so no doubts about that, I am just wondering where should I notice/experience the issue? If you accessed many small files in a random order you might see the performance difference. When accessing large files linearly you may not. The read-ahead on the disk and the buffering probably take care of the sector offset. If you are getting 80+MB/s I'd say leave it alone... it is better than many get with any drive.
November 9, 201015 yr Thanks Joe L., in this case probably I will leave it like this until the next drive comes in and I'll do the migration then. Will save me some headache So you say data integrity is not in risk at all?
November 9, 201015 yr Thanks Joe L., in this case probably I will leave it like this until the next drive comes in and I'll do the migration then. Will save me some headache So you say data integrity is not in risk at all? Not unless you change the jumper setting and expect the data to all be where it was without the jumper.
November 9, 201015 yr I thought some users reported silent data corruption when not using a jumper? Never that I remember. Yes, if you remove or add the jumper AFTER you add data, that data will not be accessible because it is now one sector offset from where it was, and all the geometry and partitioning information will not be found properly. I've never found any post stating the data was in jeopardy with or without a jumper. If you've seen one, post a link.
November 9, 201015 yr No, I'm probably remembering incorrectly. If someone did have such a problem, I'm sure you would have been the one to help them, so I'll trust your memory over mine.
November 12, 201015 yr Author If I have been told that a drive has bad sectors (I cannot confirm myself yet--more on that later), can I safely run the preclear on it to truly give me an idea of the state of the drive? Bear with me on my explanation. A few weeks ago my Drobo kept rebuilding its array. When I sent in the encrypted diagnostic file to their support, they told me that the drive in the 4th bay was "going bad" and to RMA it. So I did. Replaced that drive, and the array rebuilt itself fine. This morning I got another error. I sent in the diagnostic file, and they told me to RMA the drive because it has 3 bad sectors. Mind you this is the new warranty-replaced WD Green drive (1.5 TB). So, sure, perhaps its a coincidence that the only two drives that have failed have always been in the 4th slot. But I'm more of a conspiracy type of person and think that maybe the Drobo has an issue with the 4th bay. So... my thought is to follow the procedure I was planning on doing any way--run dd on this drive (since it's unjumpered), jumper it, run dd again, then preclear it--and see how it goes. Or should I not tempt fate and just do another RMA on the newly replaced drive? The shame of the latter would be more delay to add drives to my new unRAID box. Thanks for any insight!! Edited: Well, I went ahead and started a preclear (after writing some zeros at the beginning of the drive and jumpering it). Here is a portion of the syslog. I don't know a whole lot about this, but from reading up on S.M.A.R.T, Current Pending Sector, Offline Uncorrectable, and Multi zone error rate look like they might be pointing toward some problems, right? Nov 12 22:03:01 Tower preclear_disk-start[3540]: 1 Raw_Read_Error_Rate 0x002f 100 253 051 Pre-fail Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 3 Spin_Up_Time 0x0027 180 180 021 Pre-fail Always - 5958 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 42 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 118 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 17 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 3 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 688 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 192 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 187 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 Nov 12 22:03:01 Tower preclear_disk-start[3540]: 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 196 Thanks again!
November 13, 201015 yr Author Well, 41 minutes into the preclear and now the syslog is showing a bunch of media errors. This can't be good. But I'm going to let it finish and see what happens (unless someone suggests otherwise and I should just kill it). http://pastebin.com/1Ur4urMe I guess this one is going back to WD again on Monday.
November 13, 201015 yr Well, 41 minutes into the preclear and now the syslog is showing a bunch of media errors. This can't be good. But I'm going to let it finish and see what happens (unless someone suggests otherwise and I should just kill it). http://pastebin.com/1Ur4urMe I guess this one is going back to WD again on Monday. You can request a smart report on the drive and see what the un-readable sectors counts are up to, even before the preclear is completed, just use a different telnet session. smartctl -d ata -a /dev/sdX
November 13, 201015 yr Author Hmm... the pending sectors have disappeared. Offline uncorrectable and multi zone error rate appear to be the same, but aren't they only updated "offline"? I'm currently about 80% through the writing portion of preclear (step 2 of 10). Keep it going or is this drive a definite RMA? 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 191 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 180 180 021 Pre-fail Always - 5958 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 42 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 100 100 000 Old_age Always - 129 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 3 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 688 194 Temperature_Celsius 0x0022 124 109 000 Old_age Always - 26 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 - 187 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 - 196 SMART Error Log Version: 1 No Errors Logged
November 13, 201015 yr Hmm... the pending sectors have disappeared. Offline uncorrectable and multi zone error rate appear to be the same, but aren't they only updated "offline"? I'm currently about 80% through the writing portion of preclear (step 2 of 10). Keep it going or is this drive a definite RMA? 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 191 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 180 180 021 Pre-fail Always - 5958 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 42 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 100 100 000 Old_age Always - 129 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 3 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 688 194 Temperature_Celsius 0x0022 124 109 000 Old_age Always - 26 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 - 187 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 - 196 SMART Error Log Version: 1 No Errors Logged Keep going.... From what I've seen in the past, if all the sectors can be written successfully to their original positions, and not re-allocated, it points to them being written improperly the first time. That could ALSO indicate a poorly regulated power supply. Or a drive sensitive to noise on the power supply. If it is always the same physical slot in the array there might be an issue with the power to that slot. Let the pre-clear finish.
November 13, 201015 yr Author Thanks, Joe. Interesting indeed. My money is that this was caused by a Drobo problem. I knew I was migrating away from it for a good reason. Much appreciated!
November 14, 201015 yr Author So the preclear seems to have finished successfully. While there were some media errors on the pre-read, the log is clean on the post-read. I think this log looks fairly good? Safe to use? Or should I post this in the preclear results thread instead? Still learning the ropes on how to decipher this stuff. S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 54c54 < 1 Raw_Read_Error_Rate 0x002f 100 253 051 Pre-fail Always - 0 --- > 1 Raw_Read_Error_Rate 0x002f 200 191 051 Pre-fail Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 688 --- > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 689 65c65 < 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 192 --- > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Also attaching the saved preclear-related results. Would a full syslog be helpful as well? Thanks in advance! preclear_results.txt
November 14, 201015 yr So the preclear seems to have finished successfully. While there were some media errors on the pre-read, the log is clean on the post-read. I think this log looks fairly good? Safe to use? Or should I post this in the preclear results thread instead? Still learning the ropes on how to decipher this stuff. S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 54c54 < 1 Raw_Read_Error_Rate 0x002f 100 253 051 Pre-fail Always - 0 --- > 1 Raw_Read_Error_Rate 0x002f 200 191 051 Pre-fail Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 688 --- > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 689 65c65 < 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 192 --- > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 Also attaching the saved preclear-related results. Would a full syslog be helpful as well? Thanks in advance! Interesting.... All 192 sectors were able to be re-written to their original locations. That sure makes me suspect the power supply in the drobo box and not that disk itself. Notice also that the "normalized" read error rate value INCREASED from 100 to 200. (It is having less "raw" errors reading the disk. 200 is better than 100... A very good thing) If you have the time, you can do another pre-clear cycle... but I really don't think it is necessary, the disk is working. Joe L.
November 14, 201015 yr Author Thanks again, Joe! Really appreciate your help and expertise! I went ahead and put it in the array and it appears to be working just fine. Already copying files to it at normal write speeds. This process is doubly great for me, though, as it also confirmed I can take a non-jumpered EARS drive, write zeros, jumper it, write more zeros, and preclear it to work in unRAID. With this working drive, I can now clear out the data on the Drobo and add the remaining 3 drives to unRAID. Next step for me is to somehow convince Data Robotics that my Drobo needs warranty repair.
Archived
This topic is now archived and is closed to further replies.