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@hardwarefreak.com> 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@hardwarefreak.com> 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@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster@lists.debian.org
>> Archive: [🔎] 4F426210.6080004@hardwarefreak.com">http://lists.debian.org/[🔎] 4F426210.6080004@hardwarefreak.com
>>
>>
>
Reply to: