What LUNZ are in a first place?
When you attach storage to a server but you didn't yet assing any LUN's from storage to that server, server see something called LUNZ. You can think of LUNZ as dummy(ghost device) LUN. How many LUNZ whould you have? That's depending of how many path you have to your storage device. Each LUNZ is representing on path. So if you have 4 paths to storage, you will have 4 LUNZ, if you have 8 paths, you will have 8 LUNZ, etc.
This here is applied for EMC storage systems( Clarrion, Symmetrix, VNX, UNITY...)
Are LUNZ good or bad thing?
Seeing LUNZ are generally a good thing. This means that your server have connection to storage system. Where can you check if you can see LUNZ?#cat /proc/scsi/scsi
.
.
Host: scsi1 Channel: 00 Id: 05 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi1 Channel: 00 Id: 04 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi2 Channel: 00 Id: 05 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi2 Channel: 00 Id: 04 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
All disks are shown to system as scsi devices, same thing applied to LUNZ. Each path to storage device is represented as one LUNZ.
What can we see from above output? We can see that we have 4 paths to storage and thah we are connected to storage system with Rev number 8301.
Why this Rev number is important? In case you are troubleshooting, Rev number is uniq for storage system so in case you are not shure to which storage system your server is attached, you should loggin to serverA that already have LUN's attached to serverA and execute cat /proc/scsi/scsi and check the Rev number. If they are same as in server and serverA we can conclude that they are attached to same storage system.
Should you keep LUNZ on your system?
Only answer to this question in NO. Why? They will not do no harm but once you assing LUN to your server and rescan your scsi host, propper scsi devices will be shown and things can get a little to crowded. Even do all LUN's have uniq scsi ID multiplied by number of paths to stogare(in case you have 4 paths to storage system, one LUN is represented as 4 scsi devices, in case you have 8 paths,..) it's always wise to keep your system clean from junk. LUNZ are junk.
How to remove LUNZ?
First list your scsi devices.
#cat /proc/scsi/scsi
..
Host: scsi1 Channel: 00 Id: 05 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi1 Channel: 00 Id: 04 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi2 Channel: 00 Id: 05 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
Host: scsi2 Channel: 00 Id: 04 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
From here we can see where LUNZ are located as scsi devices.
All info you need is here:
Host: scsi1 Channel: 00 Id: 05 Lun: 2
Vendor: DGC Model: LUNZ Rev: 8301
Type: Direct-Access ANSI SCSI revision: 06
cd /sys/class/scsi_device
Here is location of all scsi devices including LUNZ.
#cd 1\:0\:5\:2/
is location of are LUNZ. How to we know this?
Host: scsi1 Channel: 00 Id: 05 Lun: 2
Bolded number are location of scsi device.
#cd device
#:/sys/class/scsi_device/1:0:5:2/device # ls
block evt_media_change modalias rescan state
bsg generic model rev subsystem
delete iocounterbits power scsi_device timeout
device_blocked iodone_cnt queue_depth scsi_disk type
dh_state ioerr_cnt queue_ramp_up_period scsi_generic uevent
driver iorequest_cnt queue_type scsi_level vendor
Let's delete scsi device
#echo 1> delete
And LUNZ is deleted. Now check scsi device list with cat /proc/scsi/scsi. Now you should see one LUNZ less then before.
Do the same thing for the rest of the LUNZ.
P.S. You should always be carefull with removing scsi devices. One mistake can be fatal for you server.
Until you assing LUN to your server, LUNZ will be appering every time you rescan you scsi host .
No comments:
Post a Comment