Bug 117381
| Summary: | utility for scsi rescan needed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Paul Barmettler <paul_barmettler> |
| Component: | kudzu | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | davidw, illtud.daniel, rsmith, rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
Internal RFE bug #117413 entered; will be considered for future releases. Is your driver actually sending the disk creation notifications correctly? How can I check this? 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. 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 <host> <channel> <id> <lun> is all digits, actually. So, you'd probably want 'scsi-add-single-device 0 0 1 0'. echo "scsi-add-single-device 0 0 1 0" > /proc/scsi/scsi works fine. 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. 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. 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. 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? 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. |
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: