|
Home > Archive > Data Storage > April 2006 > Windows 2000 and 2003 Slow LUN scan with multiple LUNs?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Windows 2000 and 2003 Slow LUN scan with multiple LUNs?
|
|
| jaylucasaustin.rr.com 2006-04-18, 12:13 am |
| Hello, I've noticed on both Windows 2000 and 2003 servers that the initial
scanning of a single external enterprise storage device that is configured
to
display many LUNs (anywhere from 16-254 LUNs per port) can take an extremely
long time. If Disk Management is open, you'll see the individual LUNs
appear
at a frequency of one every few seconds, or you might see a LUN that will
appear and disappear for a period of several minutes as all LUNs are being
scanned.
Oddly enough, if the storage device is only configured for 16 LUNs or fewer,
the scan is nearly immediate. I have seen this behaviour across multiple
Fibre Channel adapters and external storage devices, so I do not believe
that
this behaviour is HW specific. Has anyone observed this and is there a
workaround to faster scanning of large LUN configurations? Thanks.
| |
| Faeandar 2006-04-18, 12:13 am |
| On Sat, 15 Apr 2006 18:13:36 GMT, "jaylucasaustin.rr.com"
<jaylucas@austin.rr.com> wrote:
>Hello, I've noticed on both Windows 2000 and 2003 servers that the initial
>scanning of a single external enterprise storage device that is configured
>to
>display many LUNs (anywhere from 16-254 LUNs per port) can take an extremely
>long time. If Disk Management is open, you'll see the individual LUNs
>appear
>at a frequency of one every few seconds, or you might see a LUN that will
>appear and disappear for a period of several minutes as all LUNs are being
>scanned.
>Oddly enough, if the storage device is only configured for 16 LUNs or fewer,
>the scan is nearly immediate. I have seen this behaviour across multiple
>Fibre Channel adapters and external storage devices, so I do not believe
>that
>this behaviour is HW specific. Has anyone observed this and is there a
>workaround to faster scanning of large LUN configurations? Thanks.
>
The issue is Windows specific, not h/w or other s/w. I forget the
details so you should contact MS or a windows specific newsgroup for
details (unless someone here is a windows hotshot).
Also, if you leave empty spaces in LUN numbers within the first 16
LUN's windows will not pick up the LUN's after that.
For example, you have 5 LUN's you present to the host, but the
numbering leaves LUN 5 as LUN 12, you will not see it.
We ran into a few issues like this with our implementation, nothing
that's a showstopper but annoying to say the least.
~F
| |
| Maxim S. Shatskih 2006-04-18, 12:13 am |
| > Also, if you leave empty spaces in LUN numbers within the first 16
> LUN's windows will not pick up the LUN's after that.
Is the target supports REPORT LUNS - then all must be fine.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
| Faeandar 2006-04-18, 12:13 am |
| On Mon, 17 Apr 2006 07:33:26 +0400, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:
>
>Is the target supports REPORT LUNS - then all must be fine.
It's not an issue of target, happens regardless of array or hba
vendor. It's a known issue with Windows.
~F
| |
| Maxim S. Shatskih 2006-04-20, 7:08 pm |
| > >Is the target supports REPORT LUNS - then all must be fine.
>
> It's not an issue of target, happens regardless of array or hba
> vendor. It's a known issue with Windows.
Even with REPORT LUNS supported? Windows honors REPORT LUNS if it is supported
by the target. Otherwise, Windows stops at first missing LUN, and do not
continue to enumerate this target.
At least this is what MS's guys say :-)
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
|
|
|
|
|