Messages in this thread | | | From | (G.W. Wettstein) | Date | Wed, 16 Jun 1999 15:36:39 -0500 | Subject | Problems with non-filled LUNS? |
| |
Good afternoon to everyone on the list.
We ran into an interesting problem yesterday and today with 2.2.10. This isn't actually a particular problem with 2.2.10 but may be something in the generic SCSI middle layer which has been around forever.
We are deploying a Storage Area Network (SAN) at the local university and the Linux servers were the first machines that we began working on. We are working with StorageTek as the hardware vendor and the two Linux servers that we are testing with plug into each controller on a 9145 FibreChannel RAID controller. We are using Qlogic 2100 based cards and the native driver support in 2.2.10.
The drives were partitioned into two RAID5 LUNS with one LUN assigned to each controller. The problem is that one server sees its RAID5 'drive' just fine but the other server sees two RAID5 devices, one of which cannot be accessed (READ ERROR). The device that can be accessed is the one that had been assigned to the controller which the server was attached to.
One of the LUN's was defined as LUN=0 and the other was LUN=1. The machine whose storage is assigned to LUN=1 is the problematic machine. The scsi bus scan that occurs when the qlogic driver is loaded as well as /proc/scsi/scsi both report a 'phantom' LUN 0. This isn't really a problem but it does cause one of the scsi devices to be used.
We banged on the fibre-channel RAID controllers for about a day and couldn't find a problem with them. At this point I need to really give StorageTek a pat on the back. Not once did they try to blame Linux even though it isn't an officially supported attachment. There only concern was to get field experience with a Linux attachment and to make sure that the problem wasn't in their controllers.
At this point the only hypothesis that we can come up with is that Linux is 'inventing' a LUN=0 for the server which is attached to the controller whose RAID5 volume has been assigned LUN=1. The StorageTek hardware guys indicated that it isn't unheard of to have an operating system mishandle a situation like this since having no devices on LUN=0 isn't really very common. I would have to believe that someone has tried to do this with Linux in the past but perhaps not.
I am starting to look through the scsi.c code to see if I can see anything obvious in the SCSI bus scan code. The 'phantom' device reports the same Revision and model information as the true device. This may not be surprising if there is a code logic error in scsi.c.
Any comments or suggestions?
Greg
As always, Dr. G.W. Wettstein Enjellic Systems Development - Specializing 4206 N. 19th Ave. in information infra-structure solutions. Fargo, ND 58102 WWW: http://www.enjellic.com Phone: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "That's quite useful. You can set up network dongle servers." -- Alan Cox linux-kernel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |