The need is Oracle. We're running an Oracle RAC configuration which needs the device numbers for it's raw partitions and especially for ASMlib. If the device numbers change very bad things could happen. Since multipath is probably used more for enterprise applications I would think this would be a concern. I don't understand what you mean about the names being static if they start pointing to different devices. -----Original Message----- From: Christophe Varoqui [mailto:christophe.varoqui@xxxxxxx] Sent: Monday, July 31, 2006 6:03 PM To: Jeff Gibson Cc: dm-devel@xxxxxxxxxx Subject: Re: Bug in multipath detecting devices > It seems that if you have more than 26 disks/luns it will detect sdaa > before it detects sdb (sda is the onboard raid & is blacklisted). The > result is that the major/minor numbers in /dev/mapper get out of order > with the disks presented to the system. For example: > Yes. Nobody claimed mapper devices numbers are static nor even predictible. But their names really are. Actually, you shouldn't trust Linux device number at all : the dynamic device numbering idea still has fans amongst kernel developpers, I guess ;) > The major problem with this is that if I add another disk/lun in the > future sdaa will change to another disk. This is because sdaa is on > the second port of the qlogic card and gets detected as a later device > than before. When multipath comes along it creates the device in > /dev/mapper that sdaa is a member of before sdb's device is created. > As a result the multipath devices aren't in the same sequnce as the > devices that the OS detects (sdb, sdc, etc). It would be better if > sdb was always detected before sdaa. However, I don't see a way to do > that in /etc/multipath.conf without blacklisting all of the sda* drives. > Another option would be to have a user-configurable scan order, which > I don't think exists (correct me if I'm wrong). > The multipath assembly walks the device list as show by "ls /sys/block/", ie alphabetically. I still don't see the need to do it differently. Regards, cvaroqui -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
