Ensuring SAN LUN persistent names after reboot...

Sandor W. Sklar ssklar at stanford.edu
Thu Nov 1 23:42:50 UTC 2007


On Nov 1, 2007, at 3:28 PM, Arpotu wrote:

> Thanks!  I have another question now.  Using the example from the KB  
> article:
>
> KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
> RESULT="3600a0b800013275100000015427b625e", NAME="mydevice%n"
>
> Could I (for example) assign the UUID to /dev/sdb (if /dev/sdb did not
> already exist)?  Like this:
>
> KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
> RESULT="3600a0b800013275100000015427b625e", NAME="sdb"
>
> I assume yes, since the NAME could be any arbitrary string, but there
> could be a looping issue, etc.. just want to be sure before I crater  
> this
> server ;)

Hrm.  I'd assume that yes, you probably could do that, but you might  
be entering a world of pain there.

I'm not sure I'm the best person to offer practical advice on this; as  
I said earlier, I find the various interactions of HBA drivers, udev  
configuration, dm-multipath configuration, and then LVM implementation  
to be horribly, overly complicated and under-documented.

I have eight systems, each with two QLogic HBAs, connected to a SAN  
fabric of two QLogic switches, with storage from four Nexsan SATABeast  
arrays; about 60 TB of usable storage.  I've just recently discovered  
some apparently minor choices made when this was all set up is now  
causing enumerable headaches, data loss, and unplanned outages.

Personally, I would suggest that you come up with your own naming  
scheme for SAN LUNs, and use that scheme consistently (for example,  
maybe /dev/sanlun1, /dev/sanlun2, and so on.)

>
>
> Oh - one other thing.  If /dev/sda is already defined on the system,  
> and I
> comment out "options=-b", do I lose /dev/sda on next reboot, will I
> manually need to redefine it, or will nothing happen to /dev/sda?

Sorry, I can't answer that ... maybe someone else can.

	-s-

-- 
Sandor W. Sklar, Unix Systems Administrator
Stanford University Libraries & Academic Information Resources (SULAIR)
http://library.stanford.edu






More information about the redhat-list mailing list