Re: Question about HotPlug and cciss hp storage



On 2/20/2012 9:19 AM, Julien Groselle wrote:
Like I Said in the first thread :

Few people read every post in every thread. At the point I jumped in to
help, your hardware info was missing. My apologies for not back digging
the thread.

My Hardware is HP ProLiant DL380 G7, with HP Smart Array P410i Controller
version 3.50.

This is a Smart Array, and it present to the server the disk (RAID0)
directly.
So with 8 SAS HDD (8 RAID0) I have made a RAID6. Performances are amazing
comparate to hard RAID, but it is not the subject here.

Do you need something else ?

It may not matter at this point, but I'm wondering if you are using
BLK_CPQ_CISS_DA or SCSI_HPSA? Look in your loaded modules list for
something similar to these two kernel drivers. If the former, using
SCSI commands against the 8 block devices as seen by the kernel is not
going to work. If the latter, some of the SCSI tools may work.
Regardless, troubleshooting this path is a dead end. The following is
the path you need to take:

When you --fail[ed] the drive with mdadm, pulled it, and hot plugged a
replacement into the cage, the 410i firmware very likely did not
automatically create a new RAID0 array of this new disk, nor export it
as a usable device to the driver. This is very likely why you are not
finding the new disk anywhere in the sysfs.

So the solution seems rather simple. Run the HP Array Configuration
Utility (ACU). Create a RAID0 array of the new disk and export it, just
as you originally did via the BIOS ACU when you originally configured
the 8 disks. The ACU software is available here:

http://h18000.www1.hp.com/products/servers/proliantstorage/software-management/acumatrix/

Afterwards, run the normal mdadm commands to add the new disk device to
your RAID6 array.

--
Stan


Le 20 février 2012 16:09, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> a écrit :

On 2/20/2012 8:43 AM, Julien Groselle wrote:
Thank you for your answer Stan,

Yes, I'm not a specialist about this kernel data structure, but i'm on
the
way ;)
It's not so easy to find clear information about that.

So for you, if i upgrade my kernel it will be possible to use this
script... But i can't reboot production servers, and change kernel
version
like that.
I prefer ask you again the origin of my need :

I have Soft RAID using mdadm, LVM and Ext4. One of my HDD was in error,
so
i set it faulty and i remove it form my RAID array.
After i want to replace physically the HDD, so i do it.
But my Debian don't see the new HDD... I don't want to reboot...
So I started my search to how to implement HotPlug with debian Squeeze
and
HP servers.

Do you know how I can do this ?

Debian-users told me to rescan scsi, so i have tried to do that. But
maybe
you have another way to go ?

At this point you need to give us all the hardware details of the
machine with the problem. Previously you implied both machines are
HP/Compaq servers both with SmartAray controllers. Now you seem to be
saying the 2.6.32 machine does not have a SmartArray controller.
Knowing exactly how the drives are connected to the system is important
here. You now say you're using mdraid, so this would imply a mobo down
SATA chip or a non-RAID SAS/SATA HBA.

Knowing exactly how the drives are connected (preferably to what chip),
should help us tell you at minimum if hot swapping is even possible with
that hardware. With the SmartArray cards and an HP backplane it
obviously is. With a whitebox server and mobo down SATA ports, hot swap
isn't possible, except with a handful of server boards with real
hardware RAID on the mobo.

--
Stan


Thank you in advance.

--
JG.


Le 20 février 2012 14:50, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> a
écrit :

On 2/20/2012 4:47 AM, Julien Groselle wrote:
Hi,

I'm trying to understand why this directory is empty :
/sys/class/scsi_host/
We have two types of servers, one like that
# uname -r ; cat /etc/debian_version
2.6.32-5-amd64
6.0.4

And other one like that
# uname -r ; cat /etc/debian_version
2.6.39-bpo.2-amd64
6.0.4

On the first one :
# l /sys/class/scsi_host/
total 0

On the second :
# l /sys/class/scsi_host/
total 0
lrwxrwxrwx 1 root root 0 20 févr. 11:06 host0 ->
../../devices/pci0000:00/0000:00:1f.1/host0/scsi_host/host0
lrwxrwxrwx 1 root root 0 20 févr. 11:06 host1 ->
../../devices/pci0000:00/0000:00:1f.1/host1/scsi_host/host1

It drive me crazy !
Could someone explain me this difference ?

The difference is obvious: 2+ years of kernel development between
2.6.32 and 2.6.39--new features added. These are kernel data
structures, not files, after all.

It's interesting that you know where these kernel data structures are in
the filesystem, yet you apparently lack understanding of what they are,
and how they get created in the first place.

Second point, why i have this dependency for the package scsitools ?
# aptitude install scsitools
Les NOUVEAUX paquets suivants vont être installés :
libdrm-intel1{a} libdrm-radeon1{a} libdrm2{a} libgl1-mesa-dri{a}
libgl1-mesa-glx{a} libsgutils2-2{a} libutempter0{a} libxaw7{a}
libxmu6{a}
libxv1{a} libxxf86dga1{a} libxxf86vm1{a} scsitools sg3-utils{a}
tcl8.4{a}
tk8.4{a}
x11-utils{a} xbitmaps{a} xterm{a}

Apparently because this system had at one time a GUI environment, or
part of one, installed. And I would guess based on this that scsitools
has a GUI component available on GUI systems. One of my headless
servers with 2.6.38.6 and Debian 6.0.4 shows only 2 dependencies:

The following NEW packages will be installed:
libsgutils2-2{a} scsitools sg3-utils{a}

drm... mesa... i don't want this on my server, i just want rescan
scsi...
I have installed the package on a test server to read the script
/sbin/rescan-scsi-bus, and of course it stop at this line :
for hostdir in /sys/class/scsi_host/host*; do (empty in my case)

This line was my first hope : echo "No SCSI host adapters found in
sysfs" ;
Oh ! sysfs, nice way to search and it was uninstalled on my production
server.
SO i have installed it...
But /sys/class/scsi_host/ is always empty...

Any help ? :)

cciss is a *block* device driver, not a *SCSI* device driver. Thus
disks attached to a SmartArray controller cannot be directed accessed
via SCSI commands and SCSI tools. Or, at least that's how it used to
be. Apparently this distinction has been blurred between 2.6.32 and
2.6.39. It would seem the 2.6.39 cciss driver allows limited direct
access/manipulation of devices connected to the SmartArray controller
for things such as S.M.A.R.T.

--
Stan






--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact
listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/4F426210.6080004@xxxxxxxxxxxxxxxxx





--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/4F427C10.90109@xxxxxxxxxxxxxxxxx