Help with SAN/LUN mount issue?

K

kendotone

My problem is when I am trying to newfs a lun partion.

FreeBSD is seeing the LUNs and loaded them at the proper /dev/da* positions. I see that they are mounted on isp0 bus 0 scbus0 target 0 and the corresponding LUN #. I used the QLogic card BIOS and went to each LUN and did a low level format which I normally do and it works. After I do the low level format, I usually do newfs /dev/da* and then it formats to the ufs format. After that I can usually mount the /dev/da* at whichever mount point I set for it.

This time I cannot. When I newfs the device, I receive this error:

Code: 
(da15:isp0:0:0:15) SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0
(da15:isp0:0:0:15) CAM status: SCSI Status Error
(da15:isp0:0:0:15) SCSI status: Check Condition
(da15:isp0:0:0:15) SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
newfs: /dev/da15: could not open special device
Is this an issue with my hardware, FreeBSD or the way the the provider has set up the LUN on their SAN? We are using a Hitachi SAN and are using Hitech Commander 7 as their administration program.

As you can see, I am trying to newfs da15, and it is seeing it on isp0 (HBA card) at the proper targets.

Any help to my confusion would be appreciated. Thanks

kendotone.
 
Also, as I am a little newbish... What is Multipathing? How would I setup multipathing in FreeBSD? What are the benefits of it? Thanks
 
Well... I have done a lot of testing, research and asking around...and I think it comes down to the SAN LUNs not being setup properly.

Running camcontrol
camcontrol devlist -v
outputs to me the 2 different isp cards and the luns that are supposed to be attached locations.

There is a difference in the output. The LUNS that do work are labeled

Code: 
Hitachi Open-V 5900

The LUNs that do not work are labeled:

Code: 
Hitachi Open-V*3 5900

I am not sure why of this and have emailed the SAN admins to see if this is how it is supposed to be....or if something is wrong. Maybe a SAN switch went bad or something.

the camcontrol command is very useful and I recommend to anyone who does not know much about it to definitly do a [cmd=]man camcontrol[/cmd] when they have some free time =)
 
Hey,

To help with you problem in the output you posted

Code: 
CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0

The above is basically a read capacity 16 command issued by the system to determine the capacity of your disk drive. If i remember correctely a read capacity 16 command is required for LUNS of capacity greater than 2 TB.

Looking at the command issued there isn't any reason why the disk drive should issue an error. Especially the
Code: 
ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
error.

You said it was working before. Has anything changed on the hardware side (new firmware, new disks etc)? Hitachi support can help of course if you havent already tried there.
 
Shivaram said:
Hey,

To help with you problem in the output you posted

Code: 
CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0

The above is basically a read capacity 16 command issued by the system to determine the capacity of your disk drive. If i remember correctely a read capacity 16 command is required for LUNS of capacity greater than 2 TB.

Looking at the command issued there isn't any reason why the disk drive should issue an error. Especially the
Code: 
ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
error.

You said it was working before. Has anything changed on the hardware side (new firmware, new disks etc)? Hitachi support can help of course if you havent already tried there.
Click to expand...

I have not contacted Hitachi yet. I see that is the problem. Seems I need to use GPT but I have no experience with that =/ I'm trying to wing it now but its a live system and I dont want to screw anything up lol.
 
Shivaram said:
Hey,

To help with you problem in the output you posted

Code: 
CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0

The above is basically a read capacity 16 command issued by the system to determine the capacity of your disk drive. If i remember correctely a read capacity 16 command is required for LUNS of capacity greater than 2 TB.

Looking at the command issued there isn't any reason why the disk drive should issue an error. Especially the
Code: 
ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
error.

You said it was working before. Has anything changed on the hardware side (new firmware, new disks etc)? Hitachi support can help of course if you havent already tried there.
Click to expand...


Nothing has changed other than the adding of more LUNs to the card. So I guess that would be considered new disks. The original LUNs are working fine, its only the 12 new Luns at 5.36 TB that are not working. I cannot newfs, fdisk, gpart, gmultipath them. I also get the same errors.
 
Given some LUNs (the old ones) work and some don't (the new ones) it seems there's a fair chance it's something on the Hitachi side. If the new LUNs are on the same storage array then it could well be a per LUN config issue on the Hitachi, that is on these types of devices the SAN admin normally sets per LUN what the client OS will be and may have other variables that he can set too. I'd have that double checked first....

ta Andy.
 
You must log in or register to reply here.
Back
Top