#455 Issue closed: Disk Layout Generation with HP SmartArray with mor than one Logical Drive

Labels: bug, fixed / solved / done

wzwei opened issue at 2014-09-03 15:24:

I experienced a bug in the generation of the disk layout file. My tests run on a system with four
disks building two Raid-1 logical drives. As far as I understand the array configuration part in the
recovery step, there should be two "logicaldrive"-Lines in disklayout.conf. Apparently mine has
only one entry:

logicaldrive /dev/sdb 0|B|2 raid=1 drives=1I:1:1,1I:1:2,1I:1:3,1I:1:4, spares= sectors=32 stripesize=256

But it should be like that:

logicaldrive /dev/sda 0|A|1 raid=1 drives=1I:1:1,1I:1:2, spares= sectors=32 stripesize=256
logicaldrive /dev/sdb 0|B|2 raid=1 drives=1I:1:3,1I:1:4, spares= sectors=32 stripesize=256

I had a look at 27_hpraid.layout.sh. The faulty part seems to be the while-loop starting at line 54.

Regards,
Wolfgang

gdha commented at 2014-09-04 08:13:

Hi Wolfgang - understood. Could you the hpraid-config.tmp file so it is easier for me to follow?

wzwei commented at 2014-09-04 10:31:

hpraid-config.tmp:

,----
| Smart Array P410i in Slot 0 (Embedded)
|
| array A
|
| logicaldrive 1 (279.4 GB, RAID 1, OK)
|
| array B
|
| logicaldrive 2 (279.4 GB, RAID 1, OK)
|
| physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
| physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, OK)
| physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
| physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
`----

This is the actual Smartarray config:
,----
| # hpacucli ctrl slot=0 pd all show
|
| Smart Array P410i in Slot 0 (Embedded)
|
| array A
|
| physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
| physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, OK)
|
| array B
|
| physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
| physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
|
`----

wzwei commented at 2014-10-02 12:55:

Hi Gratien,

any advaneces here?

gdha commented at 2014-10-06 09:50:

@wzwei sorry too busy with other projects (earning money gets priority as with free as beer I cannot make a living :)
Please have a look into the script /usr/share/rear/layout/save/GNU/Linux/27_hpraid_layout.sh which is doing the work in your case. In case you find a bug do not hesitate to propose a pull request.

wzwei commented at 2014-10-06 10:20:

Hi Gratien,

gdha notifications@github.com writes:

@wzwei sorry too busy with other projects (earning money gets priority as with free as beer I cannot make a living :)

Same here. Erning money is sometimes very important ;-)

Please have a look into the script
/usr/share/rear/layout/save/GNU/Linux/27_hpraid_layout.sh which is
doing the work in your case. In case you find a bug do not hesitate
to propose a pull request.

I will have look. Let's see what I can do.

Regards,
Wolfgang

wzwei commented at 2014-10-06 15:38:

I found the issue. The script generates two listings: one for the logical drives and one for the
physical drives. On a system with more than one logical drives you loose the connection of logical
and physical drives! See the example output from my earlier post.

In my opinion the correct way would be to run "$HPSSACLI ctrl all show config". This command is
mentioned in the script as "the order logicaldrive and array could be wrong". My tests on various
Smart Array Controlles (P400, P410, P420) with different drive configurations showed no problems.

So I would go back to the older version of the script with the command above.

wzwei commented at 2014-10-06 15:58:

Investigated on the history of 27_hpraid_layout.sh . Issue #208 introduced the current behavior:

About a year ago hpacucli introduced a different order of arrays and logical drives. I would say
this was a bug in hpacucli! Current versions of hpacucli (9.40.12.0) all show the correct order.

Therefore I ask to change the code back to the way it worked before #208.

schlomo commented at 2014-10-06 16:11:

If there is a known broken version of hpacucli then IMHO we should maybe
add code to recognize that version and warn the user or even abort ReaR.
Especially if we know that this version leads to recovery problems.

On 6 October 2014 17:58, Wolfgang Zweimueller notifications@github.com
wrote:

Investigated on the history of 27_hpraid_layout.sh . Issue +208 introduced
the current behavior:

About a year ago hpacucli introduced a different order of arrays and
logical drives. I would say
this was a bug in hpacucli! Current versions of hpacucli (9.40.12.0) all
show the correct order.

Therefore I ask to change the code back to the way it worked before #208
https://github.com/rear/rear/issues/208.


Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/455#issuecomment-58039669.

gdha commented at 2014-10-07 11:42:

@pavoldomin your input is certainly welcome as SME.

wzwei commented at 2014-10-07 14:26:

The release notes of hpacucli show nothing about fixed bugs. Maybe @pavoldomin can check his setup with a current version of hpacucli.

Another note: It seems that HP supports both hpacucli and hpssacli! I am able to install both tools
from the same source (http://downloads.linux.hp.com/SDR/repo/spp/RedHatEnterpriseServer/). But
hpssacli delivers a bit more information than hpacucli. Nothing to worry now.

pavoldomin commented at 2014-10-07 14:46:

Hi,

I agree with @wzwei it was hpacucli bug and I agree with @schlomo, the code should parse the output correctly regardless the hpacucli version. Did a small survey here; seems that only hpacucli version 9.30.15.0 suffers by the bug. Older as well as newer versions print the ctrl config correctly.

Simple condition like:

   if //"command" is hpacucli// && hpacucli version | grep -q '9.30.15'; then //current parsing code//
   else //old parsing code//

should do it. I can pull a patch myself, but not soon, October does not look realistic :(

@wzwei: hpacucli is obsolete, replaced by hpssacli in the Sept. 2013 HP SPP.

gdha commented at 2015-02-16 16:06:

added to the release notes so we can close this issue


[Export of Github issue for rear/rear.]