This post is more than 5 years old
52 Posts
0
9595
October 2nd, 2008 14:00
Linux Lun ID Limit of 255
Linux has a Lun ID limit of 255, i presented devices to the Linux hosts, but the LUN IDs are coming up as greater then 255...
Is there something i can do when presenting these devices to fix this? I can't see any direct correlation with the LUN ID and the Device ID... we have other devices with a higher Device ID but the Linux host sees them fine so they have a lower LUN ID... ideas?
Is there something i can do when presenting these devices to fix this? I can't see any direct correlation with the LUN ID and the Device ID... we have other devices with a higher Device ID but the Linux host sees them fine so they have a lower LUN ID... ideas?
No Events found!
bodnarg
2 Intern
•
385 Posts
0
October 3rd, 2008 04:00
The LUN that gets presented to the host is a function of the LUN ID assigned to the specific FA port you assign the symmetrix device. There is no correlation between the symmetrix ID and the LUN ID. In fact to make things more confusing if a host is multi-pathed to a device down multiple FAs you could have different LUN IDs for the same device on different paths.
What version of microcode are you running? If you have 72 or above you can use Volume Dynamic Lun addressing which allows you to set the LUN ids for each specific initiator instead of by target (FA) cards.
This functionally means every server could have LUN 0, LUN1, etc. assigned to it and avoid these silly OS/hardware limitations
For a large Windows/Linux environment that reason alone is enough to want to upgrade to 72 code if you are not already there. One more caveat - you would need to be at ECC 6.0 to support this through the GUI, but I believe you need ECC 6.0 to support a box running 72 microcode anyhow.
Hope this helps.
dernsber
52 Posts
0
October 2nd, 2008 14:00
Symmetrix system - DMX3.
Using ECC to allocate the storage.
Anyone know why Linux has this limit? (and supposedly, Solaris too)
tazal
59 Posts
1
October 2nd, 2008 14:00
Depending on your setup the answer will vary but we should be able to help you out here.
tazal
59 Posts
1
October 3rd, 2008 07:00
this morning.. the LUN ID is specific to the FAs and
how many devices go down them.
Unfortunately we are only at microcode 5771.100, but
we are running ECC6.0, upgrading to 6.1 soon.
That functionality sounds perfect, i'll talk to our
CEs about the possibility of this. For now, we'll
have to figure out a workaround i guess...
Thanks!
If you can't get to 72 code for dynamic lun addressing (like how clariion and invista addressing works, very nice and highly recommended) you do have another option at 71 code.
It's a little clunky and there are some limitations but it's an option. It's called lunoffset and is also done within the masking database. Let's say you have your luns for a host starting at decimal 300. You could use a lun offset to have lun 300 on the FA be lun 0 on the host for that HBA/FA combination (you'll have to do a lun offset for each HBA/FA combo).
The downside is that any lun below the offset will be completely invisible, including your VCM if that is lun 0. That may not be a problem for you but you should be aware of it. Also keep in mind that you can offset once but not skip mulitple sets of lun addresses. So if you offset by 300 your host will have 300-555 available as 0-255. If a lun is addressed at 600 it would be shown as 300 to the host after offsetting and if your host didn't like >255 you still could not see it.
The basic concept is that your shifting your lun numbers for that HBA on an FA and just skipping a certain number of them. Note that your FA addresses will no longer match your host addresses in this case.
Check out the symmask man page and give it a try if you don't think you can get to 72 any time soon.
dernsber
52 Posts
0
October 3rd, 2008 07:00
Unfortunately we are only at microcode 5771.100, but we are running ECC6.0, upgrading to 6.1 soon.
That functionality sounds perfect, i'll talk to our CEs about the possibility of this. For now, we'll have to figure out a workaround i guess...
Thanks!
dernsber
52 Posts
0
October 6th, 2008 07:00
Would performing the LUNOffset interfere with the current produciton disk?
tazal
59 Posts
0
October 6th, 2008 08:00
worried about on that one is the host already has
disk allocated to it, configured, and in use...
Would performing the LUNOffset interfere with the
current produciton disk?
The existing disks that are allocated would have their target lun ids shifted by the lunoffset so they would essentially go away at one address and show up at another. You may be able to do one path at a time to do it non disruptively from an application perspective but that'd be more up to your multipathing software than anything. As you enable lunoffset it will definitely disrupt the path you enable it on.
Also keep in mind if they happen to have a lun at a low id you might not gain much by lunoffsetting.
Idan
3 Apprentice
•
675 Posts
0
October 18th, 2008 18:00
I may have a different solution for the issue stated above.
Instead of using LunOffset, you can simply increase the LUN ID limit at your HBA Settings. It could be done only on a Linux which is running kernel v2.6 and above.
If I remember correctly, The supported 'max luns" setting (Thats the Highest LUN ID parameter) is 1024 for QLogic and Emulex HBAs...
By Increasing that parameter, your server can 'see' higher lun IDs .
Cheers,
Idan.