It seems like many others I have installed some of these drives without installing the jumper between pins 7 and 8.  I have 7 in total.

 

There should be a major warning here somewhere not to do this.  

 

Anyway I am now trying to recover the system and started with the parity drive last night.  Parity rebuilt OK but I was getting many i-o errors when booting.  Tried a parity check that was going OK but occasionally everything would stop and lots of i-o error messages were written to the syslog and then things would start moving again.  I aborted it about 70% done as although parity was good these errors are obviously not.

 

I am now running a preclear on the drive and will try it again when the preclear finishes.

 

From what I have read on the forum it appears using these drives without the jumper can cause some data in the Master Boot Record to confuse the system once the jumper has been added.  I am guessing that preclear will get rid of this data (hopefully) and I'll then be able to use the disk ok.

 

My question is this . . . . .is there a fast way to overwrite the MBR and format these drives.  They have all been precleared already (without the jumper) so I know the drives are good.  I just need to get them into compatibilty mode as quickly as possible.  Running 7 preclears for a second time seems like a real slow way to achieve this.

 

I am a linux idiot so if you know of a command that can achieve this please spell it out in words of 1 sylable  .  Thanks muchly.

 

 

If you did even the smallest amount of research about these drives on these forums you'd have run into all the warnings and advice given to always install the jumper before you do anything. I fail to see how 1 more warning when combined with the dozens and dozens or more warnings would have done any good.

My question is this . . . . .is there a fast way to overwrite the MBR and format these drives.

Yes, there is.

Step 1.  Zero the first few blocks on the disk.

 

dd if=/dev/zero of=/dev/sdX count=2 bs=512

(Make sure you have the correct device...  or you'll be needing to fix the data disk you zeroed by accident)

 

Fixing the MBR and partitioning is described in this post: http://lime-technology.com/forum/index.php?topic=8166.msg79121#msg79121

 

Note, the unraid_partition_disk.sh script will not check if you've used the correct disk device, but... it only writes what should be there already, so for most disks it should not hurt anything.  It creates one partition, exactly as unRAID would.   It will NOT be marked as pre-cleared. If you have a parity drive assigned unRAID will clear the newly added drives as its first step and it will do it with the array off-line.  

 

I strongly suggest you un-assign your parity drive, then assign these drives, then re-assign the parity drive and let it re-calc parity.  At least that way the array is not taken off-line for many hours.

 

I have absolutely no idea if this will fix your errors being logged.  Keep us informed.   From what I've seen so far, there have been mixed results.  Many just RMA the drives.  Personally, I've just not used any advanced format drives so I've not had to deal with the issues.

 

Thanks for that Joe.

 

Brit you are right but who would think to research a disk drive when your neck deep in all the other aspects of setting up a new system for the first time.  I think that's why so many people have fallen into this hole despite the obvious warnings IF you do a search on WD20EARS.  It certainly never occurred to me to do that.

It never occurred to me to not do research on any item I'm about to purchase as a consumer, especially with technology products. I never imagined people would be so careless with their data. *shrug*

 

 

Well Brit, I guess I'll just have to hope that one day I grow up to be as smart as you

 

For anyone else following this saga, the preclear finished on the parity drive and I'm happy to report all the i-o errors went away.  I am now rebuilding parity.

 

I've decided I will use the preclear on all the disks, one at a time then rebuild the data on each one from parity. Running it with the -n -N option it took 9 hours to do a 2 terabyte drive and I can live with that.  I'm a little worried to try some of the other solutions given my obvious ignorance on all things linux and unraid.  I'll report back here how long each step takes for anyone else who finds themselves in a similar position.

Unfortunally I'm one of those guys who reading forums AFTER getting into trouble.

I have one WD Black for parity and 4 WD Green (WD20EARS) already loaded with data on it. And no compatibility jumper set. I heard about the problem before, but thought it is in the past with ancient OSs like XP. I didn't notice any performance degradation when run preclear, it was may be 20% slower than Black, but I thought it is normal for Greens. I think it is random read/write performance that is affected the most.

Anyway I want to fix the jumpers.

 

Step 1.  Zero the first few blocks on the disk.

dd if=/dev/zero of=/dev/sdX count=2 bs=512

(Make sure you have the correct device...  or you'll be needing to fix the data disk you zeroed by accident)

 

Can someone confirm that this method will work without full preclear run that takes more than 24 hours?

I have 4 data drives to fix.

 

If the above command works, then, I assume, I can just pull one EARS, set jumper, run the above command, put drive back in and run array restore (repeat for each drive)

Is it correct?

 

Thanks

Can someone confirm that this method will work without full preclear run that takes more than 24 hours?

I have 4 data drives to fix.

 

 

 

Thanks

This did not work for me and I had to preclear.

I rebuilt parity overnight.  It took about 9 hours.

 

This morning I started on the first data disk.  After un-assigning it in devices, I powered down installed the jumper and powered up again.  It's a 2 terabyte disk.  Interestingly with the jumper installed the system rebooted without the i-o errors I got when I jumpered the parity disk.  This gave me a small dilemma.  Without the i-o errors it may well be possible to just rebuild the disk and avoid the preclear.  However in the end I decided better safe than sorry so ran a preclear on it with the -n -N options again.  That only took 6 hours 50 minutes as opposed to the 9 hours it took without the jumper. 

 

I have now started to rebuild the data and so far all is well.  The system says it will take 350 minutes (5.8 hours) but I expect it will slow down as it proceeds and will probably be another 9 hour job.  I'll report back when it finishes.

 

 

Just to finish the story . . .

 

Have now finished all 7 disks successfully.  It took on average 17 hours per disk to run the preclear (with -n -N parameters) and then the rebuild.  Some of the disks when jumpered caused a heap of errors in the syslog when rebooting and some did not (no idea why this is).  However all disks completed the change OK.

 

My write speeds increased from around 15-20 MB to 30-40 MB.  

 

I can't specify exactly what was going on with the unjumpered disks but the system appeared somewhat flakey.  Sometimes it would not reboot, sometimes I'd lose access to the GUI and a few other odd things were happening.  I can't say this was because of the unjumpered disks but I can say that all the problems seemed to go away once all disks were jumpered.  

That's a significant speed increase.  Glad it worked out for you.

 

Did you follow this guide on the wiki?  If so, anything you feel needs to be changed or made easier to understand?

I also ran into problems with the Advanced format WD20EARS drives. I had the drives before building the unRAID server. It would have been nice if the main unRAID page had a note about the drives.

 

I tried removing the drives from the array, installing the pins 7-8 jumper, then allowing the drives to rebuild, one at a time. It took a week to go through 5 data drives. This method did not work for me. On startup, I get about 9 minutes of error messages before the log in displays. I then moved 8.6 gigs off the unRAID server to a Windows computer.

 

I formatted each 2 TB drive with a Windows computer to test them, and they appeared to function normally. I then installed the 2 TB drives back in the unRAID server with the pins 7-8 jumpers installed. I have the 9 minutes of errors before the unRAID login prompt. I ran a 'initconfig', then 'unassigned' all the drives from unRAID, and ran 'initconfig' again. I rebooted the unRAID server and still have 9 minutes of errors before the log in prompt.

 

I then did the following 'step 1' process for the drives that will become the parity and data drives:

 

Step 1.  Zero the first few blocks on the disk.

dd if=/dev/zero of=/dev/sdX count=2 bs=512 

 

I am now running preclear on the parity drive and the 5 data drives. I don't know what the -n -N switches are needed, so I did not use the switches.

 

After the preclear completes, do I simply assign all drives to the unRAID server? Or, after the preclear completes, do I need to temporarily assign each drive to the cache drive to format each drive before assigning each drive to the array? I am hoping to eliminate the 9 minutes of error messages each time the unRAID server is rebooted.

 

The attached syslog-11-09-2010 file is before the preclear was started on each drive.

 

Dave

 

syslog-11-09-2010.txt

I'm no expert but from what I've read and my own experience you MUST do a preclear on these drives with the jumper in place.  It appears to me that some data in the Master Boot Record is screwed up when you use these drive unjumpered and the preclear process gets rid of that messed up data.  

 

If you don't preclear it then in some cases numerous errors occur during the boot process.  Things still work but obviously this is not a good situation.

 

The preclear does a preread and a post read of each disk before zeroing out all sectors.  Each one of these reads takes about 9 hours on my system resulting in a 27 hour process to do a full preclear on 1 x 2 tb disk. If you use the -n and -N option the pre and post read is not performed which means in my case the preclear takes 9 hours instead of 27 hours.  This obviously does not exercise the disk or check for errors as would a full preclear but as I had already precleared the disks without the jumper I was not worried about the integrity of the disk , I just wanted to get the job finished ASAP.

 

The preclear command with the -n -N option looks like this . . .

 

preclear_disk.sh -n -N /dev/sd?

 

where ? = a or b or c  . . . .  etc.

 

Once the preclear is finished you can assign these drives as new ones and they will just be added to the array as new space.  If, as in my case they were previously in the array and had data on them then you assign them back to their old position, start the array and the data is rebuilt from parity.

 

 

Thanks for the response!

 

I have 1 parity drive and 5 data drives that are all WD20EARS drives. I had about 8.6 TB of data on the drives. I unassigned each drive, powered down, put the pin 7-8 jumper in, powered up and rebuilt the drive. I did that process with each of the 5 data drives and the parity drive. I did not do a preclear after the pin 7-8 jumper was installed. I continued to have about 9 minutes of errors upon startup, even if I have all the drives unassigned. Maybe I should have done a preclear on each drive, one by one after I installing the pins 7-8 jumper.

 

My second attempt to resolve the 9 minutes of errors upon startup was to copy all the data to a Windows computer with a lot of drives. That took about a week to copy 8.6 TB of data. I then did the "step 1" command listed above on each WD20EARS drive. I don't know if that was necessary. I then started a preclear on each drive. I will probably have to wait till tomorrow morning for all the drives to get done.

 

After the preclear scripts are done, I don't know if I need to assign each drive, one by one, to the cache drive to format them. Then assign them to parity or data drives. Or, maybe I can simply assign each drive to the parity and data drives, and let unRAID format them.

 

I will test my unRAID server after the preclearing scripts are done, and find out if the server still has 9 minutes of errors during the startup, or if that fixes that problem. I did not have any noticeable startup errors when I tested unRAID with small 80 - 250 gig drives, or with the WD20EARS drive without the jumper (before I knew that the pins 7-8 jumper needed).

 

Dave

Just want to note that I was not able to run preclear with the jumper when drive was connected to 8-port SAS card. I was getting zillions IO errors in log, progress was ticking at abnormal speed (something like 800MB/sec), but no data was written to the drive. I managed to run preclear after I connected drive to MB's SATA port. After that SAS card was able to use it.

After the preclearing completed, I tested rebooting the unRAID server. The 9 minutes of errors upon startup are gone. The log in prompt displays about 1 minute after booting from the USB flash drive. I added the cache drive, parity drive, and data drives 1 - 4 to the array, and the unRAID server still starts up normally, with a log in prompt about 1 minute after starting booting from the USB flash drive. The parity drive is now building. After the parity building is completed, I will have to start copying over 8.6 TB of data.

 

I never was successful connecting a data drive to a Linux computer to verify that the data is visible from the Linux computer. I would like to determine how the data can be seen and copied from the data drives independent of unRAID to verify that the files can be recovered from the data drives without unRAID.

 

Dave