Clearing Confusion on AF Drives


Recommended Posts

  • 2 weeks later...
  • Replies 95
  • Created
  • Last Reply

Top Posters In This Topic

So I need some help with "upgrading" my un-jumpered WD20EARS drives to the new 4k-aligned format. One drive is a data disk and the other is the parity drive. I would like to upgrade both so they are 4-k aligned. Version 4.7b1 seems to be running fine with my current settings, so I am ready.

 

Joe posted previously:

"Then the only people who will have to do something unusual is those who already have a EARS drive with no jumper and who wants to get it re-built on sector 64.  They would have to un-assign the drive, start the array without it assigned, overwrite the MBR making it invalid (with a simple one-line command), then stop and re-assign the drive.  It will then be recognized as its own replacement and re-constructed on a partition starting on sector 64."

 

A few questions:

1) How do you overwrite the MBR to make it invalid? Is this really required?

2) In this scenario, would the parity drive reconstruct the data even if the parity is on a drive aligned with sector 63?

 

I was thinking of doing the following:

1) Take the parity drive offline (yes I am comfortable with this, all of my data is backed up in other places)

2) Invalidate the MBR on the parity drive (???Required???)

3) Reformat the parity drive with 4k-alignment and assign it as a data disk

4) Move/Copy all data from my other EARS drive to the now 4k-aligned empty data disk

5) Invalidate the MBR on the other EARS drive (???Required???)

6) Reformat the other EARS drive with 4-k alignment and assign it as the new parity disk

 

Will this plan work or would you experts recommend purposely wiping out the data disk and relying on the parity drive to rebuild?

 

Link to comment

So I need some help with "upgrading" my un-jumpered WD20EARS drives to the new 4k-aligned format. One drive is a data disk and the other is the parity drive. I would like to upgrade both so they are 4-k aligned. Version 4.7b1 seems to be running fine with my current settings, so I am ready.

 

Joe posted previously:

"Then the only people who will have to do something unusual is those who already have a EARS drive with no jumper and who wants to get it re-built on sector 64.   They would have to un-assign the drive, start the array without it assigned, overwrite the MBR making it invalid (with a simple one-line command), then stop and re-assign the drive.  It will then be recognized as its own replacement and re-constructed on a partition starting on sector 64."

 

A few questions:

1) How do you overwrite the MBR to make it invalid?

As described.

 

Stop the array

un-assign one of the drives (can only do one at a time)

Start the array with it u-assiged

Type

dd if=/dev/zero count=8 of=/dev/sdX

(where sdX = the device of the disk being "converted")

Is this really required?
Yes, otherwise, the disk will be re-constructed with the partition as it was, since the MBR defines a valid partition.

2) In this scenario, would the parity drive reconstruct the data even if the parity is on a drive aligned with sector 63?

[/quote[Yes, it will.    Parity is relative to the start of the first partition on each of the disks, not relative to beginning sector of the physical disk.

I was thinking of doing the following:

1) Take the parity drive offline (yes I am comfortable with this, all of my data is backed up in other places)

2) Invalidate the MBR on the parity drive (???Required???)

3) Reformat the parity drive with 4k-alignment and assign it as a data disk

4) Move/Copy all data from my other EARS drive to the now 4k-aligned empty data disk

5) Invalidate the MBR on the other EARS drive (???Required???)

6) Reformat the other EARS drive with 4-k alignment and assign it as the new parity disk

 

Will this plan work or would you experts recommend purposely wiping out the data disk and relying on the parity drive to rebuild?

 

Lots of ways to handle this, since you have the data elsewhere.  Yes, you must invalidate the MBR on each disk, otherwise it will be used as is, with the partition starting in the same place as it was.  Your way would work as well.

 

Joe L.

Link to comment
  • 2 weeks later...

Just a quick question - is there any way to confirm that a drive has in fact been changed to a sector 64 alignment?  I just finished going through the steps discussed above on a f4 drive that I had in the array and would just like that peace of mind that everything is switched over correctly.

Link to comment

Yes, using the following command. It will display any partitions and the starting sector. If it's 4K-aligned it should list '64' as the Start.

 

fdisk -l -u /dev/sd#

 

For instance on my system on a non-aligned disk fdisk -l -u /dev/sdh shows:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdh1              63  3907029167  1953514552+   0  Empty

 

Edited to force sector display

 

Link to comment

Yes, using the following command. It will display any partitions and the starting sector. If it's 4K-aligned it should list '64' as the Start.

 

fdisk -l /dev/sd#

 

For instance on my system on a non-aligned disk fdisk -l /dev/sdh shows:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdh1              63  3907029167  1953514552+   0  Empty

 

 

 

The correct command on my 4.7 version is

fdisk -l -u /dev/sdX

where sdX = the device being tested.

 

If you do not use the "-u" option most versions of fdisk will give you the starting cylinder, not the starting sector.

 

For example:

root@Tower:/boot# fdisk -l /dev/sdb

 

Disk /dev/sdb: 251.0 GB, 251000193024 bytes

255 heads, 63 sectors/track, 30515 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               1       30516   245117344+   0  Empty

Partition 1 does not end on cylinder boundary.

root@Tower:/boot# fdisk -l -u /dev/sdb

 

Disk /dev/sdb: 251.0 GB, 251000193024 bytes

255 heads, 63 sectors/track, 30515 cylinders, total 490234752 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start         End      Blocks   Id  System

/dev/sdb1              63   490234751   245117344+   0  Empty

Partition 1 does not end on cylinder boundary.

 

Since this was a drive that was precleared, I could convert the partition to one starting on sector 64.

I did that using

preclear_disk.sh -C 64 /dev/sdb

 

Then I tried the  two fdisk commands once more.  If I did not specify the -u option I still got the partition starting on the same cylinder

If I do use the -u option, I can easily see the starting sector.

root@Tower:/boot# fdisk -l /dev/sdb

Disk /dev/sdb: 251.0 GB, 251000193024 bytes

255 heads, 63 sectors/track, 30515 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               1       30516   245117344    0  Empty

Partition 1 does not end on cylinder boundary.

root@Tower:/boot# fdisk -l -u /dev/sdb

Disk /dev/sdb: 251.0 GB, 251000193024 bytes

255 heads, 63 sectors/track, 30515 cylinders, total 490234752 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start         End      Blocks   Id  System

/dev/sdb1              64   490234751   245117344    0  Empty

Partition 1 does not end on cylinder boundary.

 

Joe L.

 

Link to comment

The correct command on my 4.7 version is

fdisk -l -u /dev/sdX

where sdX = the device being tested.

 

If you do not use the "-u" option most versions of fdisk will give you the starting cylinder, not the starting sector.

 

Wow, I did not know that. In the Slackware current distro it looks like they changed the default to sectors, though on unRAID 5.0b3 it doesn't look to have any particular default. Learn something new every day from these forums.  :)

 

Usage:

fdisk [options] <disk>    change partition table

fdisk [options] -l <disk> list partition table(s)

fdisk -s <partition>      give partition size(s) in blocks

 

Options:

-b <size>            sector size (512, 1024, 2048 or 4096)

-c[=<mode>]          compatible mode: 'dos' or 'nondos' (default)

-h                    print this help text

-u[=<unit>]          display units: 'cylinders' or 'sectors' (default)

-v                    print program version

-C <number>          specify the number of cylinders

-H <number>          specify the number of heads

-S <number>          specify the number of sectors per track

Link to comment
  • 3 weeks later...

To clear my confusion I hope I don't confuse you all.

Please be patient with my newbie etiquette.

 

I just put 4.7 together, I have two ERS drives (WDC_WD20EARS-00M_WD-WMAZA1768151) with no jumpers and one ST32000542AS_5XW2A377.

 

Upon my new install of 4.7 and the drives everything seemed to be fine with the exception of one of my EARS came up with 1000+ errors when I did the parity check. Ra the parity check again and the errors were chopped in have. On the third try I had 0 errors. So at that point I decided to build through with that.

 

I got nervous when I started reading MANY different ways to go about adding the jumpers and the reasons for doing so or not doing so. After making this subject on these past few pages, I have come to conclude that I do not need to make any changes and I will be fine with my current setup.

 

Could someone (a global master hero - perhaps, or the alike) verify this for me and if possible - give me the correct information concerning my experience, i.e., did the several parity checks positioned the start of partition 1 on sector 64 on this one drive...or should I have saved my syslog before reboot to post?

 

Should I perform any tests on that one ears drive that had these errors. Ever since the errors 0'd out all has been fine.

 

Advice appreciated.

 

Thanks,

Camel

Link to comment

Camel, refer to reply #55 just above your post a few. Joe has explained how to test for the partition on sector 64.

 

As for the disks errors, try pulling a SMART report. The errors should have nothing to do with the setup or install. See if the pending or reallocated sector counts show a number other than zero.

 

http://lime-technology.com/wiki/index.php?title=Troubleshooting#Obtaining_a_SMART_report

 

Peter

Link to comment

Just saw this video on the concept of / reasons behind AF (4k) drives.

 

Except for the animation of the drive!  Good grief, does no one with actual technical knowledge actually look at these before they go out to the public?

You thought the disk heads were moving in an odd arc too?  ??? ??? ??? ???

 

Perhaps they are increasing the number of possible tracks by reading them with both the leading edge of the disk head AND the trailing edge. 

(Now we know why some 3TB drives show up as 2TB drives) ;)

 

Joe L.

Link to comment

When I built my unRaid box last year I wasn't aware of this whole AF thing, so I had installed a bunch of EARS drives without the jumper and ran unRaid 4.56 just fine.

 

I've recently upgraded to the latest 5 beta and after reading this post and getting confused by the wiki, do I need to do anything here? I noticed in the webGui there is an option to select 4k aligned. should I select it?

 

If some bright spark could clarify that would be great.

 

Thanks.

Link to comment

I have found that there is no performance difference on the Samsung F4 HD204UI 2TB drive (AF drive) with 4K alignment or not.

 

I discovered this after forgetting the -A switch when preclearing four drives and then reformatting one as 4K aligned.  No discernible difference between the two when copying files to them with no parity installed yet.

Link to comment

I have a system running version 4.5.4 with a WD 2TB EADS drive as my parity drive.  I jumpered it before adding it into the system and all is good.

 

I am about to add another 2TB drive (WD EARS).  Since 4.7 is now out and I can install this new drive without the jumper, I am wondering if there would be any benefit to replacing the existing jumpered parity drive with the new unjumpered drive and then adding the old jumpered parity drive as a new data drive in the array?  Or should I just leave the system as is, and add the new un-jumpered drive as a new data drive in the array?  Would there be any difference in performance or reliability in either configuration?  All of these changes would take place after first upgrading the system to 4.7 of course!

 

Any comments or advice would be appreciated.

Link to comment

I have a system running version 4.5.4 with a WD 2TB EADS drive as my parity drive.  I jumpered it before adding it into the system and all is good.

 

I am about to add another 2TB drive (WD EARS).  Since 4.7 is now out and I can install this new drive without the jumper, I am wondering if there would be any benefit to replacing the existing jumpered parity drive with the new unjumpered drive and then adding the old jumpered parity drive as a new data drive in the array?  Or should I just leave the system as is, and add the new un-jumpered drive as a new data drive in the array?  Would there be any difference in performance or reliability in either configuration?  All of these changes would take place after first upgrading the system to 4.7 of course!

 

Any comments or advice would be appreciated.

 

EADS drives should never be jumpered.  I don't know what the jumper does on EADS drives, but it does not do the same thing as it does on an EARS drive.  I would first look at the EAD's drive's label and see what the jumper actually does.  Chances are you can remove it without consequences.

 

All new EARS drives you can run without jumpers as long as you set the MBR: aligned setting in unRAID 4.7 or newer and use the -A option in preclear.  For any old already jumpered EARS drives, just leave the drives alone, there's no performance benefit to be gained from removing the jumper.

Link to comment
  • 4 weeks later...

so i installed a new (from newegg new to me and new to array) EARS WITH jumper using 4.6 final then upgraded to 5.0beta6a. i was focused on another problem didnt realize i didnt need the jumper if formated with anything later than 4.6.1. so what will this do for me? performance hit? i dont have any data on there should i just format it with 5.0beta6a? thanks

 

***nevermind i just formated it and now its aligned so feel free to answer the question for future people if you want...thanks

Link to comment

so i installed a new (from newegg new to me and new to array) EARS WITH jumper using 4.6 final then upgraded to 5.0beta6a. i was focused on another problem didnt realize i didnt need the jumper if formated with anything later than 4.6.1. so what will this do for me? performance hit? i dont have any data on there should i just format it with 5.0beta6a? thanks

 

***nevermind i just formated it and now its aligned so feel free to answer the question for future people if you want...thanks

 

Aligned with a jumper is wrong, just like it has been every other time this was answered/explained.

Link to comment

so i installed a new (from newegg new to me and new to array) EARS WITH jumper using 4.6 final then upgraded to 5.0beta6a. i was focused on another problem didnt realize i didnt need the jumper if formated with anything later than 4.6.1. so what will this do for me? performance hit? i dont have any data on there should i just format it with 5.0beta6a? thanks

 

***nevermind i just formated it and now its aligned so feel free to answer the question for future people if you want...thanks

is it?

 

What does

fdisk -l -u /dev/sdX

say?

 

If the drive still has the jumper, and it says the partition starts on sector 64, it will NOT perform best.

If the drive has NO jumper and it says the partition starts on sector 63, it will NOT perform best.

 

Anything else is OK.

Link to comment

I am a noobie and just build my first 14 bay NAS...apologies to the mods if this should be in another section.

 

I have run into an issue trying to add a new WD20EARS (non-jumpered).  I am just purchased unraid pro v4.7 and tried to preclear the 20EARS with the 4k alignment active.  The preclear hdd speed was ~14 MB/s and 50% complete on step 1 after ~11hours.

 

I have stopped the preclear checked the drive speeds and swapped drive position.  The issue follow the drive NOT the bay/sata; my other three drives (x1 750 GB, x2 -2 TB Hitachi) precleared and work fine.

 

Likewise, the hdparm for the drive is below:

/dev/sdd:

Timing cached reads:   2618 MB in  2.00 seconds = 1308.64 MB/sec

Timing buffered disk reads:    4 MB in  9.41 seconds = 435.43 kB/sec

 

Any thoughts on this?  Do I need to RMA the drive, add the jumper (? - thought that I was all set with 4.7 and latest preclear) or just brute force the preclear?

 

Thanks.

 

B

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.