unRAID Server Release 4.7 "final" Available


limetech

Recommended Posts

  • Replies 414
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

It's been a while since I dealt with the 4.x series, so this may not be fully accurate...

 

It's HPA related. You'll need to take care of that. I think my signature has a link to HPA, what it is and what it means for you. Of particular note:

 

Special Note regarding unRAID 4.7

If you are upgrading from unRAID 4.6 (or below) to unRAID 4.7 (or above) you MUST remove any HPAs on any of your drives BEFORE the upgrade can be successful.  See this thread [ http://lime-technology.com/forum/index.php?topic=10483.msg99685#msg99685 ] for more information.

 

 

 

Jul  7 12:56:23 Tower kernel: ata7.00: HPA detected: current 1953523055, native 1953525168

Jul  7 12:56:23 Tower kernel: ata7.00: ATA-8: ST31000340AS, SD15, max UDMA/133

Jul  7 12:56:23 Tower kernel: ata7.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 0/32)

Jul  7 12:56:23 Tower kernel: ata7.00: configured for UDMA/100

Jul  7 12:56:23 Tower kernel: scsi 7:0:0:0: Direct-Access    ATA      ST31000340AS    SD15 PQ: 0 ANSI: 5

Jul  7 12:56:23 Tower kernel: sd 7:0:0:0: [sde] 1953523055 512-byte logical blocks: (1.00 TB/931 GiB)

Jul  7 12:56:23 Tower kernel: sd 7:0:0:0: [sde] Write Protect is off

Jul  7 12:56:23 Tower kernel: sd 7:0:0:0: [sde] Mode Sense: 00 3a 00 00

Jul  7 12:56:23 Tower kernel: sd 7:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Jul  7 12:56:23 Tower kernel:  sde: sde1

Jul  7 12:56:23 Tower kernel: sd 7:0:0:0: [sde] Attached SCSI disk

 

Jul  7 12:56:23 Tower kernel: ata8.00: HPA detected: current 1953523055, native 1953525168

Jul  7 12:56:23 Tower kernel: ata8.00: ATA-8: WDC WD10EADS-00L5B1, 01.01A01, max UDMA/133

Jul  7 12:56:23 Tower kernel: ata8.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 0/32)

Jul  7 12:56:23 Tower kernel: ata8.00: configured for UDMA/100

Jul  7 12:56:23 Tower kernel: scsi 8:0:0:0: Direct-Access    ATA      WDC WD10EADS-00L 01.0 PQ: 0 ANSI: 5

Jul  7 12:56:23 Tower kernel: sd 8:0:0:0: [sdf] 1953523055 512-byte logical blocks: (1.00 TB/931 GiB)

Jul  7 12:56:23 Tower kernel: sd 8:0:0:0: [sdf] Write Protect is off

Jul  7 12:56:23 Tower kernel: sd 8:0:0:0: [sdf] Mode Sense: 00 3a 00 00

Jul  7 12:56:23 Tower kernel: sd 8:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Jul  7 12:56:23 Tower kernel:  sdf: sdf1

Jul  7 12:56:23 Tower kernel: sd 8:0:0:0: [sdf] Attached SCSI disk

Jul  7 12:56:23 Tower kernel: ata10.00: HPA detected: current 1953523055, native 1953525168

Jul  7 12:56:23 Tower kernel: ata10.00: ATA-8: ST31000340AS, SD15, max UDMA/133

Jul  7 12:56:23 Tower kernel: ata10.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 0/32)

Jul  7 12:56:23 Tower kernel: ata10.00: configured for UDMA/100

Jul  7 12:56:23 Tower kernel: scsi 10:0:0:0: Direct-Access    ATA      ST31000340AS    SD15 PQ: 0 ANSI: 5

Jul  7 12:56:23 Tower kernel: sd 10:0:0:0: [sdi] 1953523055 512-byte logical blocks: (1.00 TB/931 GiB)

Jul  7 12:56:23 Tower kernel: sd 10:0:0:0: [sdi] Write Protect is off

Jul  7 12:56:23 Tower kernel: sd 10:0:0:0: [sdi] Mode Sense: 00 3a 00 00

Jul  7 12:56:23 Tower kernel: sd 10:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Jul  7 12:56:23 Tower kernel:  sdi: sdi1

Jul  7 12:56:23 Tower kernel: sd 10:0:0:0: [sdi] Attached SCSI disk

Link to comment

Thanks for the suggestions so far.

 

The server is based on a HP XW4400 so not a Gigabyte board (probably Intel or Foxconn), and I can't find HPA settings anywhere in the BIOS. I don't think these drives were used with another mobo, but can't be sure.

 

I logged in as root and tried running this:

 

hdparm -N p1953525168 /dev /sde

 

but got:

 

HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device

HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device

/sde : no such file or directory

 

 

Link to comment
I logged in as root and tried running this:

 

hdparm -N p1953525168 /dev /sde

 

but got:

 

HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device

HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device

/sde : no such file or directory

 

Remove the space in /dev/sde

Link to comment

curiously, all the affected drives are on the same PCI controller...

 

can i roll back to by 4.5 by simply restoring the original files to my flash?

yes, you can revert to 4.5 in exactly that way.

 

you can then fix the HPA (by removing them, one, by one, and letting unRAID re-construct each in turn.)

You can only do one at a time, as unRAID has to use all the other disks to re-construct the one where you just the HPA.

 

Joe L.

Link to comment

Thanks Joe. I also tried unsuccessfully to use HDAT2, so ended up rolling back for now. I need to get to V5 though for large drive support, so was glad to see another option.

 

I found this FAQ about removing a disk from the array: http://lime-technology.com/wiki/index.php/FAQ#On_versions_of_unRAID_prior_to_4.5.4

 

(note the 'prior to 4.5.4' - I only see "version: 4.5" in the top right of the console)

However I assume that this would result in data loss once parity ran? If I were to use the process above to remove one of the HPA drives, how would I add it back into the array without data loss?

 

I also found this FAQ regarding replacing a drive with another: http://lime-technology.com/wiki/index.php/FAQ#How_do_I_replace_a_hard_disk.3F

 

Is this a safer method?

 

Since I have 3 affected drives, would the process be to:

- remove the first drive, install the new

- update drive assignment and restart the array

- wait for preclear, data rebuild and run parity check

 

    - remove the second drive, and replace with the first

    - update drive assignment and restart the array

    - wait for preclear, data rebuild and run parity check

 

        - remove the third drive, and replace with the second

        - update drive assignment and restart the array

        - wait for preclear, data rebuild and run parity check

 

Seems like a slow process, but also the safest?

Link to comment

If pre-clear doesn't remove HPA, then I'm back where I started... as I've already tried the suggested methods for removal on that page.

 

hdparm fails with "HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device". I have no idea what the issue is, and a quick google only seems to return unrelated results.

 

HDAT2 fails to load drivers/detect devices when used with either a USB and SATA DVD drive. Maybe it's to do with a PCI expansion card? All I can think of is to remove the drives from the unraid server, add them to another PC (to an onbaord SATA port) and to run HDAT2 from there.

Link to comment

If pre-clear doesn't remove HPA, then I'm back where I started... as I've already tried the suggested methods for removal on that page.

 

hdparm fails with "HDIO_DRIVE _CMD(identify) failed: inappropriate ioctl for device". I have no idea what the issue is, and a quick google only seems to return unrelated results.

 

HDAT2 fails to load drivers/detect devices when used with either a USB and SATA DVD drive. Maybe it's to do with a PCI expansion card? All I can think of is to remove the drives from the unraid server, add them to another PC (to an onbaord SATA port) and to run HDAT2 from there.

 

That hdparm error usually indicates an incorrect syntax in your hdparm command, such as a space after the '/dev'.  Also, if you get the 'HPA setting seems invalid' error, it appears that at least sometimes, the command actually still worked, so reboot and try the hdparm -N command again, to see what the new MAX is.  Hopefully it will now be correct, ending in 168.

Link to comment
  • 1 month later...

Not to dig up an old thread, but I hit the snag that is mentioned in this thread today. I upgraded from 4.6 to 4.7 in order to then move to a 5.0rc version in order to use a new 3TB drive as my parity drive. After rebooting to 4.7 I'm getting the "disk to small error" and I haven't done anything more. Is there something I can do to fix this in 4.7 and then move on to a 5.0rc or do I even need to worry about going to 4.7 between 4.6 and a 5.0rc? Syslog attached. Thanks in advance for any help.

syslog-2012-08-28.txt

Link to comment

Not to dig up an old thread, but I hit the snag that is mentioned in this thread today. I upgraded from 4.6 to 4.7 in order to then move to a 5.0rc version in order to use a new 3TB drive as my parity drive. After rebooting to 4.7 I'm getting the "disk to small error" and I haven't done anything more. Is there something I can do to fix this in 4.7 and then move on to a 5.0rc or do I even need to worry about going to 4.7 between 4.6 and a 5.0rc? Syslog attached. Thanks in advance for any help.

You could upgrade the way I did.  I was without parity protection for 12-24 hours.  I put all drives into a fresh unRAID install (no drives selected) V5.0 beta.  Added them all as data drives.  Saw ONE drive unformatted moved that to parity and had it rebuild the parity on that drive in V5.0 beta again.  Then ran new permissions once parity was built.  But like I said that was without parity protection for an extended period of time.  All of my drives were 2TB in size and all WD green - mixture of EADS and EARS with jumpers. Almost forgot to mention I upgraded PCs at the same time.  Went from X7SBE Celeron 430 2xSAT2-MV8 HBAs to a X9SCM Xeon E31230 ESXi with unRAID VM and M1015 HBA and SAS expander.
Link to comment

Would doing something like that get me around the HPA issues for good or would it just be a temp fix? If it's something I can do without too much trouble I would like to go ahead and get rid of the HPA now once and for all. I'm not using a mobo with HPA now, but the drive in question was connected to one earlier in it's life. Thanks.

Link to comment

Would doing something like that get me around the HPA issues for good or would it just be a temp fix? If it's something I can do without too much trouble I would like to go ahead and get rid of the HPA now once and for all. I'm not using a mobo with HPA now, but the drive in question was connected to one earlier in it's life. Thanks.

It won't fix the HPA it would only get you onto 5.0 and is NOT the recommended way to upgrade.  I threw it out there as a last resort.  Hopefully someone else can help you get rid of the HPA first so that you can upgrade to 4.7 then 5.0 as is recommended.
Link to comment

Would doing something like that get me around the HPA issues for good or would it just be a temp fix? If it's something I can do without too much trouble I would like to go ahead and get rid of the HPA now once and for all. I'm not using a mobo with HPA now, but the drive in question was connected to one earlier in it's life. Thanks.

 

I had the same problem and with the same intentions, went back to 4.6, and then removed the hpa from each drive, one at a time, and have it rebuild using the parity. After all (3) were done, I upgraded to 4.7 and everything was fine...

 

But using this technique, you will be without parity protection during each rebuild (in my case 3 times). Of course I did know that even the disk which was being rebuild was being written with data already on it (Except for the last few bytes), so in case of problems I would only loose the data on any broken disk during rebuild and not the drive which was rebuilding, unless it was the same drive, in that case I would have no problems... ;)

Link to comment

Can you point me to the steps you used to correct the HPA on each drive? I see some instructions on page 1 and 2 of this thread, but they seem user/case specific. Thanks.

 

I used Joe L's comment : http://lime-technology.com/forum/index.php?topic=7042.msg68253#msg68253

 

Ofcourse you need to have the numbers of sectors for your specific drive. As I had other disks of the same type but without the HPA this was easy.

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.