unRAID Server Release 4.7-beta1 Available


limetech

Recommended Posts

I guess I am a bit confused.  Is all data lost on a disk when the jumper is removed and changed to advanced format?  However, parity will then rebuild the drive and things will be OK?

 

Next, does it matter if the Parity drive is AF vs not when rebuilding the new disk?

 

Can I test with 4.7b1 with drives with jumper in place before taking the plunge and pulling it?  I have 2 new drives and am trying to decide what to do.  Do I upgrade and format with the -A or wait for gold release?  If I do remove the jumper of an existing drive, what is actually happening?  the drive gets formated, data lost and parity rebuilds?  Or am I way off and missing something completely about the process.  I have 1 advanced format drive now and want to add 2, but I want the least work moving forward.  My understanding is that it really doesn't matter, but what is the real opinion?  Is this upgrade more for those without WD that can use the jumper fix or is 64bit AF recommended for all moving forward?

 

 

 

 

Link to comment
  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

I guess I am a bit confused.  Is all data lost on a disk when the jumper is removed and changed to advanced format? 

Yes, basically all data on that physical disk is lost if the jumper setting is changed.
However, parity will then rebuild the drive and things will be OK?
It will if it can write to the drive.  Most times the drive will lock up and not be readable or writable until power cycled.

It has been determined that if you zero out the first few sectors the disk can be made to work once more (after a power cycle)

Next, does it matter if the Parity drive is AF vs not when rebuilding the new disk?

No.

Yes.  If you do nothing at all, all will be exactly as it was on 4.6.

Can I test with 4.7b1 with drives with jumper in place before taking the plunge and pulling it?  I have 2 new drives and am trying to decide what to do.

Up to you.
Do I upgrade and format with the -A
-A does not "format"  It puts a pre-clear signature in place after completely writing zeros to the drive that asks that the partition that will be created by unRAID start on sector 64.
or wait for gold release? 
Again up to you.
If I do remove the jumper of an existing drive, what is actually happening? 
Electrically, the jumper was adding 1 to the sector numbers being requested.  Sector 63 actually accessed a 4k aligned sector 64. Sector 64 requested accessed sector 65, etc.  You remove the jumper and a request for the data that is on sector 63 gets what is on 63... In other words the data is all offset and you get back garbage instead of what is expected. 
the drive gets formated, data lost and parity rebuilds?
None of the above.
  Or am I way off and missing something completely about the process.  I have 1 advanced format drive now and want to add 2, but I want the least work moving forward.  My understanding is that it really doesn't matter, but what is the real opinion?  Is this upgrade more for those without WD that can use the jumper fix or is 64bit AF recommended for all moving forward?

If on 4.7 onward, select the MBR 4k-aligned setting in the settings page.  Do not add or delete existing jumpers on drives already in the array.  Do NOT add jumpers to new AF drives.  Use the "-A" option to the pre-clear script.

 

Joe L.

Link to comment

I guess I am a bit confused.  Is all data lost on a disk when the jumper is removed and changed to advanced format? 

 

I'll just point out that removing the jumper doesn't gain anything. It DOES NOT change the drive into an AF drive. Leave the jumper and leave the drive formatted with a sector 63 partition.

 

Joe pretty much has it covered. Just leave the jumpered drives alone. The only reason to do anything with a EARS drive is if you have unjumpered disks in your array that are formatted to sector 63. Even then, if they are working fine for you you don't have to mess with them either.

 

Peter

 

Link to comment

So I am tempted to run this build in a production environment for the Advanced Format support. As I have 2 drives that are going through the break in process that support advanced formatting so if I upgrade I can prevent any hard drives in Unraid having the wrong formatting.

 

 

 

Any ideas when this goes final? Normally I have patience, but I have been filling drives just as fast I have been adding them so delaying the install of these 2 drives is not optimal.  Just wondering what the usual time frame is from Beta to final, especially since so much work is going on with 5.0 these days.

 

 

Link to comment

Will the Samsung F4 EcoGreen 2TB drives work with this release?

 

Yes, they should work with the firmware update. The forum is looking for someone with one of these drives willing to test unRaid 4.7 with a Samsung F4.

 

Can you direct me to this firmware issue? What firmware is required by the F4 before use in 4.7?

 

[EDIT] Never mind, here's a thread: http://lime-technology.com/forum/index.php?topic=9339.0

Link to comment

Upgraded from 4.6final to 4.7beta1.

 

3 disks that had a known pre-existing HPA partition showed up differently, all 500 GB.  I can't remember if this was before/after choosing '4k alignment' in settings.

 

From 488,385,496 to 488,385,492, difference of 4 KB.

 

Unraid acknowledged the difference, offered option to import... I choose yes.  Upon further thought decided to check filesystem, sure enough reiserfs was corrupted on same three disks.  Had mirrors of disks stored offline, used hdat to finally expunge HPA then break parity -> reformat -> reimport data -> build parity.

 

My fault on not dealing with HPA earlier with due diligence.

Link to comment

I guess I am a bit confused.  Is all data lost on a disk when the jumper is removed and changed to advanced format? 

Yes, basically all data on that physical disk is lost if the jumper setting is changed.
However, parity will then rebuild the drive and things will be OK?
It will if it can write to the drive.  Most times the drive will lock up and not be readable or writable until power cycled.

It has been determined that if you zero out the first few sectors the disk can be made to work once more (after a power cycle)

Next, does it matter if the Parity drive is AF vs not when rebuilding the new disk?

No.

Yes.  If you do nothing at all, all will be exactly as it was on 4.6.

Can I test with 4.7b1 with drives with jumper in place before taking the plunge and pulling it?  I have 2 new drives and am trying to decide what to do.

Up to you.
Do I upgrade and format with the -A
-A does not "format"  It puts a pre-clear signature in place after completely writing zeros to the drive that asks that the partition that will be created by unRAID start on sector 64.
or wait for gold release? 
Again up to you.
If I do remove the jumper of an existing drive, what is actually happening? 
Electrically, the jumper was adding 1 to the sector numbers being requested.  Sector 63 actually accessed a 4k aligned sector 64. Sector 64 requested accessed sector 65, etc.  You remove the jumper and a request for the data that is on sector 63 gets what is on 63... In other words the data is all offset and you get back garbage instead of what is expected. 
the drive gets formated, data lost and parity rebuilds?
None of the above.
  Or am I way off and missing something completely about the process.  I have 1 advanced format drive now and want to add 2, but I want the least work moving forward.  My understanding is that it really doesn't matter, but what is the real opinion?  Is this upgrade more for those without WD that can use the jumper fix or is 64bit AF recommended for all moving forward?

If on 4.7 onward, select the MBR 4k-aligned setting in the settings page.  Do not add or delete existing jumpers on drives already in the array.  Do NOT add jumpers to new AF drives.  Use the "-A" option to the pre-clear script.

 

Joe L.

 

Perfect, Thanks for the response Joe.

 

So basically it is up to me to do beta or not.  Beyond that, I just need to not be so OCD that I need all jumpered or not jumpered disks.  I can add my disks now on 4.6 and when 4.7 goes gold, I just set the 4k setting and moving forward new disks have no jumper, while leaving the rest alone.  Or, if it is really going to bother me.  I can go to 4.7 beta now and remove the jumpers.  Either way my data is safe, it is more a matter of how crazy I am about keeping things the same across the board.

 

Perfect, it is all up to me...

 

Thanks again for the response.  Give me a better understanding of it all.

Link to comment

So I now have this beta running on both my home and office Unraid servers. No problems so far. I am using the preclear script now on an advanced format drive at home so I will try adding a new drive sometime over the weekend depending on how long the clear takes.

 

 

 

 

 

Link to comment

Upgraded from 4.6final to 4.7beta1.

 

3 disks that had a known pre-existing HPA partition showed up differently, all 500 GB.  I can't remember if this was before/after choosing '4k alignment' in settings.

 

From 488,385,496 to 488,385,492, difference of 4 KB.

 

Unraid acknowledged the difference, offered option to import... I choose yes.  Upon further thought decided to check filesystem, sure enough reiserfs was corrupted on same three disks.  Had mirrors of disks stored offline, used hdat to finally expunge HPA then break parity -> reformat -> reimport data -> build parity.

 

My fault on not dealing with HPA earlier with due diligence.

 

Do you know the actual size of the HPA in sectors?  One way to get this is to examine the Devices page and look at the device identifier of the disk(s) with HPA.  The identifer is in parenthesis, for example in the line below, the identifer is "sdh":

 

disk1 device: pci-0000:00:1f.5-scsi-0:0:0:0 host4 (sdh) ST380811AS_5PS2P6J7

 

Now from the console or telnet session, type this command:

 

hdparm -N /dev/<identifier>

 

For the disk above I would type:

 

hdparm -N /dev/sdh

 

Please post output of this command.

Link to comment

Upgraded from 4.6final to 4.7beta1.

 

3 disks that had a known pre-existing HPA partition showed up differently, all 500 GB.  I can't remember if this was before/after choosing '4k alignment' in settings.

 

From 488,385,496 to 488,385,492, difference of 4 KB.

 

Unraid acknowledged the difference, offered option to import... I choose yes.  Upon further thought decided to check filesystem, sure enough reiserfs was corrupted on same three disks.  Had mirrors of disks stored offline, used hdat to finally expunge HPA then break parity -> reformat -> reimport data -> build parity.

 

My fault on not dealing with HPA earlier with due diligence.

 

Do you know the actual size of the HPA in sectors?  One way to get this is to examine the Devices page and look at the device identifier of the disk(s) with HPA.  The identifer is in parenthesis, for example in the line below, the identifer is "sdh":

 

disk1 device: pci-0000:00:1f.5-scsi-0:0:0:0 host4 (sdh) ST380811AS_5PS2P6J7

 

Now from the console or telnet session, type this command:

 

hdparm -N /dev/<identifier>

 

For the disk above I would type:

 

hdparm -N /dev/sdh

 

Please post output of this command.

 

HPA has been expunged, this is current output of 3 disks that had it (hda, sdm, sdl)

 

Tower login: root

Linux 2.6.32.9-unRAID.

root@Tower:~# hdparm -N /dev/hda

 

/dev/hda:

The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.

READ_NATIVE_MAX_ADDRESS_EXT failed: Invalid argument

root@Tower:~# hdparm -N /dev/sdm

 

/dev/sdm:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~# hdparm -N /dev/sdl

 

/dev/sdl:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~#

 

Output of 2 other 500GB that never had HPA. (sdk, sdn)

 

root@Tower:~# hdparm -N /dev/sdk

 

/dev/sdk:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

 

root@Tower:~# hdparm -N /dev/sdn

 

/dev/sdn:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~#

 

Now I remember, the difference of 4 KB showed up immediately upon 1st boot of 4.7beta1, before '4K alignment' was selected.

 

 

Link to comment

HPA has been expunged, this is current output of 3 disks that had it (hda, sdm, sdl)

 

So your server is back to normal then?

 

/dev/hda:

The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.

READ_NATIVE_MAX_ADDRESS_EXT failed: Invalid argument

root@Tower:~# hdparm -N /dev/sdm

This is probably your USB flash device.

 

 

/dev/sdm:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~# hdparm -N /dev/sdl

 

/dev/sdl:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~#

 

Output of 2 other 500GB that never had HPA. (sdk, sdn)

 

root@Tower:~# hdparm -N /dev/sdk

 

/dev/sdk:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

 

root@Tower:~# hdparm -N /dev/sdn

 

/dev/sdn:

max sectors   = 976773168/3694640(976773168?), HPA setting seems invalid (buggy kernel device driver?)

root@Tower:~#

Yep unfortunately not all drivers implement ATA command necessary to muck with the HPA.

 

Now I remember, the difference of 4 KB showed up immediately upon 1st boot of 4.7beta1, before '4K alignment' was selected.

 

The issue is the HPA.  unRAID can not reliably support drives with an HPA if you also want to support transition to 4K aligned partitions and later GPT partitions (drives larger than 2TB).  Trouble is there is no reliable way I can tell in linux to consistently detect and eliminate an existing HPA as the hdparm commands above attest.

Link to comment

Just to confirm I understand things. Changing the default setting to 4k is irrelevant for my setup because i use preclear script %100 of the time correct? So no matter what, it would be up to me to remember to use the correct settings when clearing.

 

I currently have a drive clearing with the advanced format option in both my home and office 4.7 servers.

 

 

Link to comment

Just to confirm I understand things. Changing the default setting to 4k is irrelevant for my setup because i use preclear script %100 of the time correct? So no matter what, it would be up to me to remember to use the correct settings when clearing.

 

Yes, if you use Joe L.'s preclear script, that script will write an unRaid-recognized signature to the disk once all sectors have been written with zeros.  The signature can indicate either 4K align (with -A switch), or not (-A absent).  Whatever it is, when you assign the disk to the array, unRaid will not change the MBR other than to clear 'factory-erased' status after incorporated into the array.

 

The "Default partition format" setting applies when unRaid needs to write an MBR to the disk because it doesn't recognize the one that's already on there.  This can happen if you don't use the preclear script, or if preclear aborts before disk has been erased.

Link to comment

I am thinking to install 4.7 B1.  I am going to keep my one drive with the jumper in place, at least for now...

 

So, I have 2 new drive, both not in the array yet.  Both have the jumper right now and one has been pre-cleared.  If I now go back and remove the jumper from both, I will need to run pre-clear with -A on the one that hasnt been touched, but what about the other that is already cleared?  Do I have to run the whole clear again for 24 hours, or is there a faster way to handle this?

Link to comment

I am thinking to install 4.7 B1.  I am going to keep my one drive with the jumper in place, at least for now...

 

So, I have 2 new drive, both not in the array yet.  Both have the jumper right now and one has been pre-cleared.  If I now go back and remove the jumper from both, I will need to run pre-clear with -A on the one that hasnt been touched, but what about the other that is already cleared?  Do I have to run the whole clear again for 24 hours, or is there a faster way to handle this?

 

You could run preclear with the -n option, which would skip the pre and post read cycles.  That would be much faster, but you would miss out on some of the burn-in properties of preclear.

 

IF you had precleared a disk and just wanted to change the partitioning, there is a shortcut coming out that would switch the partition without a lengthy process.  But removing the jumper would interfere with the preclear process being able to verify that the preclear signature was in place, so it would not work.  Joe L. might be able to figure out how to detect a preclear signature with an EARS jumper removed, but would be some work and he doesn't have any EARS to run those tests.  I don't think such a feature would be forthcoming.

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.