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

Re: Question about HotPlug and cciss hp storage

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 ?

Thank you in advance.


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.


Reply to: