[O111111O]

Has anybody around here used SCSIDEV?

Looking for experience with static mappings of SCSI ID and LUN to /dev/ device based on WWPN and/or SN of target device.

If your not familiar with the issue, essentially Bus, and SCSI id's aren't persistent between reboots with ANY Linux kernel. This is a real pain if you're mapping app id's to SCSI targets that need to stay persistent.

[lotuseclat79]

Hi O111111O,

Yes, I happen to know that the kernel has been modified, so that is now the case, i.e. you will not find the persistence you expect. I face the same issue every day when I bring up my ext3 based file system, so I have written a script to identify and mount it for what I need to do in my situation. You situation may be different from mine so you may not be able to do exactly as I.

The best you can do is one of two things as follows:
1) At a course grain level, you can issue the following command as root:
# fdisk -l
in order to get a listing of all of your disks and how the cylinders are mapped. If that data does not distinquish between your scsi devices whereby you can positively identify the specific device by its cylinder layout, then the only really definitive way is to run the following command,
2) Given that your scsi disk has either an ext2/ext3 file system (likely for RH), then you need to install the (latest) suite of programs named e2fsprogs from sourceforge.net if they are not already installed (which they may be).

The specific command you need to run is for each particular scsi disk, the one that dumps the super block (dumpe2fs) for the file system on that specific scsi device. If the scsi device was given a specific UUID field (in the super block), then you need to perhaps write a small script that can identify it by that UUID, and then once the proper disk is identified by its UUID, run the app software against it.

Look at them man page for dumpe2fs, I think the format is something like: # dumpe2fs <devicename>
or give the name of the partition from the fdisk -l output.

I do not know specifically what kernel change was made, but the change has been made and will stay with us for at least the time until it is changed yet again for whatever reason.

-- Tom

[O111111O]

Hey lotuseclat79,

Yah. Disk isn't really the issue. Using UUID on some systems, or LVM (some FS's are multiple 5TB LUNS).

The issue is really FC attached tape libraries, auto mounters, tape drives, robots, etc. It's quite annoying when you have a system that has 80-100 tape drives + robots presented to multiple HBA's. A reboot is always a complete crapshoot.

I really wish there was something similar to /etc/path-to-inst.

[lotuseclat79]

Hi O111111O,

From what you describe, you make an interesting argument for either a kernel change counter-argument back to the static device assignment model, or as you suggest (as I am not familiar with it), something similar to /etc/path-to-inst. Perhaps you can describe it.

I would guess that no one in the kernel group was even considering the kinds and quantities of devices you are faced with administering in your situation and the effect the kernel change has had on your operation.

Why not register with the kernel mailing list (following their rules about asking questions) and post your situation and the argument about reboots being a crapshoot ever since the kernel change that affected static device assignment. Perhaps it will force the kernel group to rethink its decision - who knows? It could not hurt to ask, and then seek relief by some means from the disasterous side-effects of their decision making on your situation. Although, since they are a crafty lot, I would expect them to make plausible counter arguments.

One thing you might ask the kernel group is what was the decision criteria by which the change to the kernel was decided - did it include considerations for your situation or not, and why?

You are not the first to be affected by this change.

-- Tom