Re: preclear_disk.sh - a new utility to burn-in and pre-clear disks for quick add


Recommended Posts

There are options to that can be passed to the pre-clear script to just run parts of the pre-clear proess if you know roughly where it got to that can be used to save time.  However running from the tart will not do any damage so it might be the easiest thing to do.

Link to comment

Any way to check if a disk has been successfully precleared?

 

I've been running pre clear on a new 4TB drive in a backup server (free licence). The pre clear script was instantiated from another machine on the network.

 

When I check this morning at 6.30 AM, it was 8% through the final step.

 

Power failed sometime in the afternoon to the machine running the script but the server was unaffected.

 

I therefore can't see if the pre clear process completed. Is there a way to check if the drive has been successfully pre-cleared?

 

Thanks

 

Peter

yes, you can type:

preclear_disk.sh -t /dev/sdX

also, when complete the prclear reports are saved in the /boot/preclear_reports directory

 

however... Unless you were running the script under "screen", it stopped as soon as the connection via telnet dropped.

Link to comment
  • 1 month later...

So it's been a long time since I've had to preclear a drive.  Thursday I purchased a 3TB WD Red, can't believe how cheap they've gotten.  I'm just running through the process now.  Is there still a results page to which we can post for analysis??

 

Also, I would like to use this 3TB drive in place of a WD20EARS drive, which is jumpered.  Does this mean I will need to be careful when configuring the Red drive?  When repositioning the EARS drive in the array (I will move it to be a normal data drive) I assume I should keep the drive with the current settings sector-63 aligned I believe?

 

Many thanks guys.

Link to comment

So it's been a long time since I've had to preclear a drive.  Thursday I purchased a 3TB WD Red, can't believe how cheap they've gotten.  I'm just running through the process now.  Is there still a results page to which we can post for analysis??

 

Also, I would like to use this 3TB drive in place of a WD20EARS drive, which is jumpered.  Does this mean I will need to be careful when configuring the Red drive?  When repositioning the EARS drive in the array (I will move it to be a normal data drive) I assume I should keep the drive with the current settings sector-63 aligned I believe?

 

Many thanks guys.

 

No, the partitioning of a drive is unrelated to the starting sector of the partition. (ie., unRAID takes care of that)

 

It is a good idea to check smart reports, run a parity check, then rerun the smart reports, and make sure there are not drive anomolies before beginning the drive replacement process. You should preclear the disk first to give it a good burnin. However, the preclear signature is not needed or helpful for a drive reconstruction.

 

But I will point out that replacing a perfectly good 2T drive with a 3T drive is not very economical. There are 4T, 5T and even 6T drives that would probably be cheaper per T than spending the cost of a 3T drive to net an increase of only 1T in array size.

Link to comment
Can you preclear on unraid system A, then move the drive to unraid system B and add it to the array?
As long as the drive size and configuration aren't manipulated by System A or B, then yes. Some motherboards do bad things to drives by setting a HPA which subtracts from the size of the drive. Also, some USB drive adapters change the geometry of the drive. You should be able to check the preclear signature on the target system and tell right away if the drive is properly precleared for that system.
Link to comment

Can you preclear on unraid system A, then move the drive to unraid system B and add it to the array?

 

I tried searching but didn't find anything so I apologize in advance if it exists somewhere already.

 

Thanks.

 

Absolutely!!!  I have done it three of four times without any problems.

Link to comment

Can you preclear on unraid system A, then move the drive to unraid system B and add it to the array?

 

I tried searching but didn't find anything so I apologize in advance if it exists somewhere already.

 

Thanks.

That's the only way I've done mine.  Well almost - only - anyway.  80+ drives and counting now.
Link to comment

Can you preclear on unraid system A, then move the drive to unraid system B and add it to the array?

 

I tried searching but didn't find anything so I apologize in advance if it exists somewhere already.

 

Thanks.

Yes.    There is nothing on a pre-cleared disk that ties it to a particular system.

 

I have heard of people having a separate system specifically targeted at allowing them to run pre-clears on disks without disturbing the system running the production servers.

Link to comment

I took a 4 TB drive out of the array for a couple days to use it for other purposes. Before re-adding it to the array, I ran the preclear script against it without pre-post reads, just zero out the drive. When I added it to the array, UNRAID didn't recognize the drive as being precleared and proceeded to do it again.

Link to comment

I took a 4 TB drive out of the array for a couple days to use it for other purposes. Before re-adding it to the array, I ran the preclear script against it without pre-post reads, just zero out the drive. When I added it to the array, UNRAID didn't recognize the drive as being precleared and proceeded to do it again.

 

I thought it was the post read that marks the drive precleared for UnRAID as it does the validation.

Link to comment

I took a 4 TB drive out of the array for a couple days to use it for other purposes. Before re-adding it to the array, I ran the preclear script against it without pre-post reads, just zero out the drive. When I added it to the array, UNRAID didn't recognize the drive as being precleared and proceeded to do it again.

 

I thought it was the post read that marks the drive precleared for UnRAID as it does the validation.

No it is apparently the write step.  I have use the option to skip pre and post many times on drives and it has always worked for me.  I also do most of my preclears on my preclear station and not on my servers.  But I would let Joe respond to this question for the correct answer.

What version of the preclear script are you using?

type

preclear_disk.sh -v

to see the version.

 

What versions are the two unRAID servers? 

 

Before assigning the drive to the array, but after physically moving it to the target server, did you verify the preclear signature with

preclear_disk.sh -t /dev/sdX

??

 

(and you are correct, writing the pre-clear signature is the last step after writing zeros to the drive, but before the post-read phase)

Link to comment

Just doing my 3t green and its coming up as 63 and there's no jumper on the thing? Is this safe to add it to the array or not. This was done using the newest preclear script on another machine thats in enhanced ide sata. It was out of a windows machine off a raid 1 before hand and it shows as sector 63. Whats the deal with the sector thing anyhow?

 

edit its an fdisk issue god dammit atleaset i can stop the things and start again

 

http://linuxconfig.org/linux-wd-ears-advanced-format?zjixallipatw=ytxcavjlt

 

The preformance hit isnt that bad on riser anyhow ext3 is totaly crap though.

 

2.1. Partition table for WD EARS hard drive starting with sector 63

 

# fdisk -lu /dev/sda

 

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x10bd10bc

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sda1              63    20971583    10485760+  83  Linux

 

    ext2: 114 MB/s

    ext3: 47 MB/s

    ext4: 92 MB/s

    reiserfs: 87 MB/s

    vfat: 58 MB/s

 

2.2. Partition table for WD EARS hard drive starting with sector 64:

 

# fdisk -lu /dev/sda

 

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x10bd10bc

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sda1              64    16777280    8388608+  83  Linux

 

    ext2: 126 MB/s

    ext3: 87 MB/s

    ext4: 106 MB/s

    raiserfs: 101 MB/s

    vfat: 58 MB/s

 

It appears that ext3 file system is most crippled when disk's partition is not aligned and starts on sector 63. This test may not be the most effective benchmark as there are many more variables to be filled into the formula, however it give us some picture of what is going on. I could see the difference even on greater scale when installing back | track Linux on WD EARS drive formatted with ext3 partition starting on sector 63 ( 34 minutes ) and 64 ( 8 minutes ).

Link to comment
  • 2 weeks later...

Love the script, thanks for writing it! I've used it on every disk in my machine (9 data, 1 parity, 1 cache)

 

Currently preclearing my first 4TB drive, and it's actually zipping along quite nicely. 18 hours and is on post-read (currently ~150 MB/s) of cycle 1.

 

Just a thought for future revisions: Instead of (or in addition to) saying "DONE" next to a step when it's completed, could you put the elapsed time that step took? Or, alternatively, just the elapsed time from start would be fine - I can do the math if that's easier for the script.

 

thanks again, JoeL!

FreeMan

 

Edit: Also, anything in version 1.14* that might keep all drives in the array spinning? I don't recall having seen this behavior in the past, but I can't identify anything else going on  'round here that would be keeping every drive busy.

 

* Yes, I discovered there is now a 1.15, but I'm not running a 64-bit OS yet, so it looks like 1.14 will do for this run. I'll update as soon as it's finished.

Link to comment

Edit: Also, anything in version 1.14* that might keep all drives in the array spinning? I don't recall having seen this behavior in the past, but I can't identify anything else going on  'round here that would be keeping every drive busy.

The writing to a drive will use most of your free memory in the disk buffer cache, displacing anything previously cached.  Any other activity on the server will therefore need to spin up the physical disks to read their contents.

 

It could therefore be anything, even a PC on your lan attempting to update its directory listings.  (don't sweat it)

 

Joe L.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.