Re: Ensuring SAN LUN persistent names after reboot...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux