| Author |
Message |
Bob
Guest
|
Posted:
Wed Oct 12, 2005 12:17 am Post subject:
scsi rescan caching |
|
|
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 |
|
| Back to top |
|
 |
Jeff Goldner [MS]
Guest
|
Posted:
Wed Oct 12, 2005 8:16 am Post subject:
Re: scsi rescan caching |
|
|
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.simac@gmail.com> wrote in message
news:1129062666.434954.4970@g47g2000cwa.googlegroups.com...
[quote]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
[/quote] |
|
| Back to top |
|
 |
Bob
Guest
|
Posted:
Wed Oct 12, 2005 4:16 pm Post subject:
Re: scsi rescan caching |
|
|
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 |
|
| Back to top |
|
 |
Jeff Goldner [MS]
Guest
|
Posted:
Thu Oct 13, 2005 4:17 pm Post subject:
Re: scsi rescan caching |
|
|
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.simac@gmail.com> wrote in message
news:1129128242.962525.197670@o13g2000cwo.googlegroups.com...
| Quote: | 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
|
|
|
| Back to top |
|
 |
Bob
Guest
|
Posted:
Fri Oct 14, 2005 4:16 pm Post subject:
Re: scsi rescan caching |
|
|
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 |
|
| Back to top |
|
 |
Jeff Goldner [MS]
Guest
|
Posted:
Sat Oct 15, 2005 6:09 am Post subject:
Re: scsi rescan caching |
|
|
ah, you should have said iSCSI. Storport is not relevant then.
"Bob" <robert.simac@gmail.com> wrote in message
news:1129305605.654272.48840@z14g2000cwz.googlegroups.com...
| Quote: | 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
|
|
|
| Back to top |
|
 |
Bob
Guest
|
Posted:
Wed Nov 02, 2005 1:24 am Post subject:
Re: scsi rescan caching |
|
|
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 |
|
| Back to top |
|
 |
Jeff Goldner [MS]
Guest
|
Posted:
Thu Dec 15, 2005 5:16 pm Post subject:
Re: scsi rescan caching |
|
|
I missed this one. It's very reliable, and currently there is no way to
adjust it.
"Bob" <robert.simac@gmail.com> wrote in message
news:1130874404.133619.255590@g47g2000cwa.googlegroups.com...
| Quote: | 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
|
|
|
| Back to top |
|
 |
|
|
|
|