i'm afraid that a simple "scsi rescan" will not work - there's no such thing in kernel 2.4 (neither in kernel 2.6, before 2.6.12). we had to work for a while in order to get a rescan to work, and even then it's not a general-purpose solution.
--guy On Fri, 2006-10-13 at 20:47 +0200, Jacob Broido wrote: > Good idea, > Also, if I remmeber correctly sg3utils allows to issue a SCSI RESCAN, > which I can use to overcome the 'linux kernel not being aware of new > LUNs' issue. > > > 2.6.x really made things sane in this area. > > > > > On 10/13/06, guy keren <[EMAIL PROTECTED]> wrote: > > [since you're a top-poster, i'll top-post too ;)] > > in kernel 2.4, for SCSI disks, there is support for at most 16 > * 16 = > 256 devices. there are 16 major numbers (listed in the > kernel's > documentation), and for each of them, there are minors 0, 16, > 32, 48.... > that are used for the devices (the minors in between are used > for > partitions, which you don't seem to care about). you could > then run a > loop that scans the list of combinations, and check whether > each of them > exists. if so - they are disks - use the standard tools to get > their > info. to get vendor + model - use the sg_inq utility from > sg3utils - it > should be available for kernel 2.4 too. note that this might > also > include usb mass-storage devices (disk-on-key, cameras...), > since they > are exposed as scsi disks. > > you could also look in /proc/scsi/devices for the available > SCSI LUNs > (this will include tapes too). > > i imagine you could do a similar thing with IDE and SATA > disks. > > also note that if a new LUN is added to the network, the linux > kernel > will NOT notice it. i don't know if it matters to you, but > just FYI. > > --guy > > On Thu, 2006-10-12 at 11:46 +0200, Jacob Broido wrote: > > Hey, > > as mentioned by Amos, there is a tool called lshal, which > works in > > 2.6.x , not sure about 2.4.x - (Any comments on this?) > > lshal is much more usefull than lspci and it provides more > details > > info. > > > > The missing information from lshal is the disk size. This > can be > > easily extracted using blockdev --size <blockdev>. > <blockdev> == > > blockdev returned by lshal. > > > > 2.4.x indeed seems like a problem at the moment. > > > > > > > > On 10/12/06, Oleg Goldshmidt < [EMAIL PROTECTED]> wrote: > > "Jacob Broido" <[EMAIL PROTECTED]> writes: > > > > > Hey, > > > > > > > > > > > > I've been looking for some time for a way to list > all > > scsi,sata,ide devices > > > that are currently 'seen' by the linux host. > > > > > > > > > > > > The tool should do the following: > > > > > > 1) Find all HBAs in the host. > > > > > > 2)Query each HBA (should be HBA agnostic) > > > > > > 3) Query each device returned by HBA query, and > extract the > > following: > > > size,type,vendor > > > > With 2.6 some (most?) of what you want can be done > by quering > > and > > manipulating sysfs, e.g., > > > > echo "- - -" > /sys/class/scsi_host/host[N]/scan > > > > will do a SCSI bus scan. With 2.4 things are more > difficult, > > and there > > are tools that work for different HBAs, e.g., > scsi-qlascan for > > QLogic > > etc. Unless your device is exposed (by the driver) > in sysfs > > you will > > probably need a vendor-specific tool. > > > > Also, does "lspci -vvv" or similar give you anything > that you > > can use? > > > > If you find anything generic, a useful script or set > of > > scripts for > > 2.6, do let me know. > > > > -- > > Oleg Goldshmidt | [EMAIL PROTECTED] | > > http://www.goldshmidt.org > > > > > > > > -- > > Not gonna be king of the world if you're slave to the grind > > - Skid Row > > > > > -- > Not gonna be king of the world if you're slave to the grind > - Skid Row ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
