New Luns showing properties of old Luns assigned to Lun ID

what OS,  was the old LUN presented to the same server ?

something is hung in Windows cache, if you can run chkdsk /x /i  ..that should clear that up (it will take LUN offline).

i am sure this could be cleared by server reboot ..but that should be your last resort. So you've got into Disk management and ran rescan ? Does output from powermt display dev=all  display new symmetrix device id ?

Windows 2003. The server is assigned with a new Lun with the old Lun ID. But it was showing the properties of old lun. ie the lun size of new lun is reflecting as the size of the old lun assigned to the Lun ID

Powermt output is showing the new deivce assigned to the server. But the disk management is pulling up the old lun details which is assigned to the respective Lun ID. The issue is fixed if we use a new Lun ID where no other device is used before.

I am not sure why the Lun ID which is already freed up after reclaimation if used to present a Lun to a server showing up a the properties of old lun. The old lun is not assigned to the same server, it was presented to a different one, but still its pulling up the info: of the old lun.

But doubt is

If we have a server A where I assigned Lun X with Lun ID : 10 of 60Gb. After somedays I reclaimed the Lun X from Server A and freed up the Lun ID: 10.

After few days I assigned Lun Y to server B with same Lun ID: 10 that of 30GB. Instead of the lun showing as 30GB in the sever B disk management it is showing as 60GB. And moreover without initializing the new lun in Server B it is showing as Drive without any drive letter.

The issue is getting fixed when we reassign the Lun Y with a different Lun ID which is not used before.

I am not sure how come Windows cache of server comes into picture here...

Yes it is the address that map to the FA. We are not using Dynamic Lun masking.

i thought you are removing LUN 10 from server A, increase it in size and present it back to server A.

when you say LUN ID, are you talking about the address that you map to on the FA ? Are you using dynamic lun masking ?

Sure sounds like server B has something in cache, try that chkdsk command i gave you on server B.

Hello.

Persistent binding is the mechanism to create a continuous logical

route from a storage device object in the Windows host to a volume in

the EMC storage array across the fabric.

Without a persistent binding mechanism, the host cannot maintain

persistent logical routing of the communication from a storage device

object across the fabric to an EMC storage array volume. If the

physical configuration of the switch is changed (for example, the

cable is swapped or the host is rebooted), the logical route becomes

inconsistent, causing possible data corruption if the user application

is modifying data through inconsistent logical routing of the

communication from the driver entry point to a volume in an EMC

storage array across the fabric.

When you removed the old lun did yougo into disk management and run a scan or remove the volume so the lun would drop off?  If the powermt output shows the lun data correctly but the operating system seems to think its the old volume then as Dynamox is alluding to there is "old" information persisting regading that lun.

Are you using windows native multipathing or power path? i have seen similar cases with multipath, but not windows OS though..