Bug 117381 - utility for scsi rescan needed
Summary: utility for scsi rescan needed
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kudzu (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-03 14:52 UTC by Paul Barmettler
Modified: 2014-03-17 02:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-21 19:00:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Paul Barmettler 2004-03-03 14:52:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
Feature request:
Red Hat does not include the scsi - rescan - script with the 
Operating System. 
After adding a new scsi disk to RAID-Adapter (IBM ServeRaid) a reboot 
is required in order see the newly added disks.
This is a very antique method to get access to new disk.

Please improve system usability with an adequate utility.

Version-Release number of selected component (if applicable):
kudzu-1.1.22-1.1

How reproducible:
Always

Steps to Reproduce:
1. Insert disks into free slot of IBM ServeRaid adapter
2. Configure RAID-1 with ServeRaid Manager
3. fdisk -l doesn't list /dev/sdb
    

Actual Results:  OS doesn't recognize new hardware.
fdisk only shows /dev/sda

Expected Results:  OS should recognize new disks.
/dev/sdb shoulb be shown.

Additional info:

Comment 1 Suzanne Hillman 2004-03-03 19:26:25 UTC
Internal RFE bug #117413 entered; will be considered for future releases.

Comment 2 Bill Nottingham 2004-03-04 04:21:21 UTC
Is your driver actually sending the disk creation notifications correctly?

Comment 3 Paul Barmettler 2004-03-04 06:13:12 UTC
How can I check this?

Comment 4 Bill Nottingham 2004-03-04 06:18:23 UTC
Hm, actually, now that I think about this, the driver may not do this.

But it could.

In the meantime, 'echo "scsi-add-single-device <host> <channel> <id>
<lun>" > /proc/scsi/scsi should do it for you.

Comment 5 Paul Barmettler 2004-03-04 06:40:33 UTC
It isn't working at all.
Situation before adding disks:
cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: SERVERAID        Rev: 1.00
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 15 Lun: 00
  Vendor: IBM      Model: SERVERAID        Rev: 1.00
  Type:   Processor                        ANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 08 Lun: 00
  Vendor: IBM      Model: 32P0032a S320  1 Rev: 1   
  Type:   Processor

After configuring disks by ServeRaid Manager:
echo "scsi-add-single-device scsi0 00 01 00" > /proc/scsi/scsi
cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: SERVERAID        Rev: 1.00
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 15 Lun: 00
  Vendor: IBM      Model: SERVERAID        Rev: 1.00
  Type:   Processor                        ANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 08 Lun: 00
  Vendor: IBM      Model: 32P0032a S320  1 Rev: 1   
  Type:   Processor                        ANSI SCSI revision: 02

Comment 6 Bill Nottingham 2004-03-04 06:42:47 UTC
<host> <channel> <id> <lun> is all digits, actually.

So, you'd probably want 'scsi-add-single-device 0 0 1 0'.


Comment 7 Paul Barmettler 2004-03-04 07:43:01 UTC
echo "scsi-add-single-device 0 0 1 0" > /proc/scsi/scsi
works fine.

Comment 8 illtud 2005-07-07 14:27:49 UTC
Could I add a call for a rescan utility (the venerable rescan-scsi-bus.sh would
do!) - it really could do with being a supplied tool.


Comment 9 Randy Smith 2005-07-07 21:31:52 UTC
Note that echoing into /proc/scsi/scsi has several problems from the perspective
of any programmatic control of the process:
* There isn't an easy way to synchronize with command completion
* You don't get any failure notification if, e.g, you try and remove and then
add in a device (to reset the in-kernel store of how large it is, for instance).
It would still be very useful to provide a utility that had these attributes,
even though echoing into /proc/scsi/scsi solves the basic functionality.

Comment 10 Bill Nottingham 2005-09-21 19:00:56 UTC
Red Hat strives to work within the community of upstream open source projects.
This allows us to reduce the likelihood of regressions between releases as well
as to benefit from features and fixes as development moves forward. This change
would require a significant divergence from the upstream project and is
therefore being rejected.

Realistically, I think the best way to handle this is to have the drivers export
the right events to the SCSI midlayer when you add/remove a disk via whatever
management tool, and then you wouldn't need to echo into /proc.

Comment 11 Dave Wysochanski 2005-09-21 19:26:02 UTC
What do you mean by "have the drivers export the right events to the SCSI midlayer"?

There are SCSI check conditions that can be returned when a new LU is
added/mapped or a size changes on a target, but as far as I know the midlayer in
the 2.4.x kernels don't recognize those and rescan the bus automatically.  The
only other option is to somehow explicitly tell the kernel to rescan the bus,
which is what I thought what this bugzilla was about.

Traditionally, I thought the /proc/scsi/scsi interface was the only method to
update the kernel LU info when the mapping changed, short of removing modules
and things like that.  Is there some other method that could be used though?

Comment 12 Bill Nottingham 2005-09-21 20:05:45 UTC
Whoops, I was confusing rescan vs. hotplug at the controller level. Apologies.

However, such a rescan script wouldn't be added to kudzu; there's really no
place in kudzu for it to be run/used.

I would think, that for a management tool such as the earlier mentioned
ServeRAID manager, that it would explicitly know what host/channel/id/lun it was
modifying, and therefore could do the add/remove via /proc/scsi/scsi itself
without an external script.


Note You need to log in before you can comment on or make changes to this bug.