PeterB Posted January 15, 2011 Share Posted January 15, 2011 Maybe mid to late Feb is pessimistic, but I'm usually proven to be an optimist in the end! Even the most pessimistic person can prove to be over-optimistic when discussing IT project timescales! Quote Link to comment
johnsanc Posted January 24, 2011 Share Posted January 24, 2011 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? Quote Link to comment
Joe L. Posted January 24, 2011 Share Posted January 24, 2011 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. Quote Link to comment
Roancea Posted February 5, 2011 Share Posted February 5, 2011 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. Quote Link to comment
BRiT Posted February 5, 2011 Share Posted February 5, 2011 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 Quote Link to comment
Joe L. Posted February 5, 2011 Share Posted February 5, 2011 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. Quote Link to comment
Roancea Posted February 5, 2011 Share Posted February 5, 2011 Thanks so much for the helpful replies. Ran fdisk with the l and u switches and it looks like everything is working right! Quote Link to comment
BRiT Posted February 5, 2011 Share Posted February 5, 2011 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 Quote Link to comment
Joe L. Posted February 5, 2011 Share Posted February 5, 2011 Sure it does have a default in slackware-current.... From your own post... -u[=<unit>] display units: 'cylinders' or 'sectors' (default) Quote Link to comment
Camel Posted February 21, 2011 Share Posted February 21, 2011 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 Quote Link to comment
lionelhutz Posted February 21, 2011 Share Posted February 21, 2011 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 Quote Link to comment
keyvan Posted February 27, 2011 Share Posted February 27, 2011 Just saw this video on the concept of / reasons behind AF (4k) drives. Interesting for someone like me with limited knowledge of HD tech. http://bcove.me/fsmy7blt Quote Link to comment
bubbaQ Posted February 27, 2011 Share Posted February 27, 2011 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? Quote Link to comment
Joe L. Posted February 27, 2011 Share Posted February 27, 2011 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. Quote Link to comment
mazma Posted March 1, 2011 Share Posted March 1, 2011 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. Quote Link to comment
Rajahal Posted March 1, 2011 Share Posted March 1, 2011 If you haven't noticed any performance issues, then it is best not to mess with anything. You can still set the disk alignment option to 4k aligned, as it will only affect future disks, not your current ones. Quote Link to comment
elkay14 Posted March 8, 2011 Share Posted March 8, 2011 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. Quote Link to comment
Ned Posted March 12, 2011 Share Posted March 12, 2011 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. Quote Link to comment
Rajahal Posted March 16, 2011 Share Posted March 16, 2011 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. Quote Link to comment
carlos28355 Posted April 13, 2011 Share Posted April 13, 2011 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 Quote Link to comment
lionelhutz Posted April 13, 2011 Share Posted April 13, 2011 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. Quote Link to comment
Joe L. Posted April 13, 2011 Share Posted April 13, 2011 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. Quote Link to comment
carlos28355 Posted April 15, 2011 Share Posted April 15, 2011 well all my EARS with jumper say they start on 64 and my EADS with no jumper starts on 63 so ill try and take care of that. thanks Quote Link to comment
Rajahal Posted April 15, 2011 Share Posted April 15, 2011 Nothing wrong with an EADS starting on 63. You won't see any performance benefit by changing it to 64. Quote Link to comment
bmoney Posted April 21, 2011 Share Posted April 21, 2011 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 Quote Link to comment
Recommended Posts
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.