[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question about HotPlug and cciss hp storage

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.


> 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 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

Reply to: