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.
--
JG.
Le 20 février 2012 14:50, Stan Hoeppner <s...@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
>
>
>
