scsi rescan caching

[Bob]

Hi,

Regarding the Microsoft own rescan.exe, as found at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;308669

I have found this very utility and particulary the
CM_Reenumerate_DevNode() call, which is used within to do actual bus
rescan, are behaving as if there is some caching involved.

Test as follows:
1. run rescan over and over, from command line, as fast as you can (or
write a shell script to do it)
2. Observe how long does it take, each time, for rescan to finish

You will see the very 1st rescan does take some time to finish while
all subsequent are returning IMMEDIATELLY.
Then again, after 30 or some iterations, rescan AGAIN takes some time,
as if it actually doing something. I made no device additions in that
time. Machine was idle. Test is reproducible.

Note I did above test with both NORMAL and CM_REENUMERATE_SYNCHRONOUS
setting for CM_Reenumerate_DevNode(), same behaviour.

Any thoughts on this?

Thanks,

Robert

[Jeff Goldner [MS]]

you must have fast fingers then ;)

Most likely what you are observing is the 30 second timer in scsiport. For
30 seconds following a rescan, we do in fact return cached information. That
was put in to address the abundance of IoInvalidateDeviceRelations calls
that we seem to get.

"Bob" <robert...@gmail.com> wrote in message
news:1129062666....@g47g2000cwa.googlegroups.com...

[Bob]

Jeff,

Thanks for the prompt and detailed answer.

And now, inevitable follow up:

Is there a way to force the proper rescan, not the cached one?

I know it's slow and will not abouse it, but the notion my rescan call
is maybe getting stale data, depending on whether I or someone else did
rescan <30secs ago, is not making me very comfortable.

Thanks,

Robert

[Jeff Goldner [MS]]

no, I'm afraid all you can do at this point is include a delay in your
application. We are investing better mechanisms. If you have a Storport
miniport available, that might work better.

"Bob" <robert...@gmail.com> wrote in message

news:1129128242.9...@o13g2000cwo.googlegroups.com...

[Bob]

Thanks for the answer, Jeff.

Since I'm living in application/user space, the mention of
'storport/miniport' was somewhat new to me, but after brief googling I
got familiar with the terms at least, and optimistically concluded your
suggestion of "if you have Storport miniport available" translates to
"it will work on win2003"...

However, same test on my win2003 SP1 enterprise server yielded the very
same results. Here are more test details for there may be hidden an
explanation...

Goal: From my windows workstation, to detect the newly mapped iscsi LUN
from nearby Netapp filer, in timely, non delayed manner. Also, to
detect such LUN's unmapping.
We shall not involve iSCSI intitiator in this picture for this new
lun(s) are part of same, previously, established iscsi connection (no
iscsi logins/outs involved).
Merely, fast detection of 'someone' on netapp box exposing/destroying
luns to my workstation. Mind you, new luns are detected always, but
after 30secs. My goal is to avoid this.

Tested with: W2k3 SP1, latest iSCSI initiator, latest download of
'storport'.

Regards,

Robert

[Jeff Goldner [MS]]

ah, you should have said iSCSI. Storport is not relevant then.

"Bob" <robert...@gmail.com> wrote in message

news:1129305605....@z14g2000cwz.googlegroups.com...

[Bob]

Jeff,

How reliable is the value of 30 sec in "30 second timer in scsiport"?
Is there any registry entry where I can read/verify this timer value
before arranging my code to depend on such value.
I need dependable detection of newly added iscsi drive, and I'm ok with
waiting N seconds, as long as I'm sure I'll see the added change.

Thanks,

Robert

[Jeff Goldner [MS]]

I missed this one. It's very reliable, and currently there is no way to
adjust it.

"Bob" <robert...@gmail.com> wrote in message

news:1130874404.1...@g47g2000cwa.googlegroups.com...