How to remove LUNZ from LINUX - EXPLAINED and SOLVED

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 .

WARNING: Re-reading the partition table failed with error 22: Invalid argument. - SOLVED and EXPLAINED

In case you have this WARNING while creating partition on multipath device

 WARNING: Re-reading the partition table failed with error 22: Invalid argument. 

don't panic.

# fdisk /dev/mapper/mpatha
Partition number (1-4): 1
   First cylinder (1-19074, default 1):
   Using default value 1
   Last cylinder or +size or +sizeM or +sizeK (1-19074, default 19074):
   Using default value 19074

   Command (m for help): p

   Disk /dev/mapper/mpatha: 156.8 GB, 156892397568 bytes
   255 heads, 63 sectors/track, 19074 cylinders
   Units = cylinders of 16065 * 512 = 8225280 bytes

                            Device Boot      Start         End      Blocks   Id  System
   /dev/mapper/mpathap1               1       19074   153211873+  83  Linux

   Command (m for help): w
   The partition table has been altered!

   Calling ioctl() to re-read partition table.

   WARNING: Re-reading the partition table failed with error 22: Invalid argument.  <------
   The kernel still uses the old table.
   The new table will be used at the next reboot.
   Syncing disks.

Depending on you Linux distro, there can be also suggestion that you reboot server or use parted or kpartx so that new partition table be used.

In case you have this error, first you should check if kpartx see newly created partition with

kpartx -l /dev/mapper/mpatha
mpatha1 : 0 33552384 /dev/mapper/mpatha 2048

This means that kpartx can normally see partition on multipath device mpatha. In other words, new partition table is already applied.

P.S. Don't mind the numbers on last command.