File system I/O not cancelable?

NTFSD
1

It appears that cached file system I/O which results in paging I/O cannot be
canceled on Server 2003.

The IRP for the cached I/O is on the thread’s IRP list. Ntfs holds this
IRP, but does not set a cancel routine.

CcCopyRead generates a page fault to fill the cache. The IRP to satisfy the
page fault goes to the volume driver (my driver), which sets a cancel
routine. However, this IRP has not been placed on the thread’s IRP list.

So, if the volume driver takes a long time to process the IRP (for the sake
of the argument, say, forever), and, for example, the user types control-C
at his “type” command, the cached IRP cannot be canceled because it has no
cancel routine, and the non-cached IRP cannot be canceled because it is not
associated with the thread. And we continue to hang.

Is there anything that can be done to allow these I/O’s to be canceled? Or
am I stuck timing out in the volume driver (with what, unfortunately, needs
to be a relatively long timeout)?

At the last plugfest, Microsoft indicated that filters that hold IRPs for
any substantial period should set a cancel routine. Will the physician also
heal himself in this case?

Thanks,

  • Dan.
2

Traditionally, none of the local file systems have supported I/O
cancellation directly (the term “directly” is of course because they do
so indirectly via the FsRtl routines for oplocks and directory change
notifications for example.) Presumably the idea is that these
operations should complete “quickly” and thus do not fall into the world
in which the hideous complexity of I/O cancellation becomes involved
(hey, file systems are bad enough, right?)

Given that Windows Server 2003 is a legacy system, and that this
behavior is consistent with the behavior since, oh, NT 3.1, I suspect
you’ll have a difficult time making a business case for changing this
behavior.

I am curious - you restricted your comments to Windows Server 2003.
Have you tried this on Vista and found that it DOES support I/O
cancellation (which could be through the magic of file object queued
IRPs of course.)

A quick think on this suggests there might be some hideous non-timeout
related solutions, but I stopped thinking about it quickly, realizing I
didn’t want to return my breakfast. :wink:

And of course NTFS wouldn’t be covered by the admonishment because it is
not a filter - it’s a file system, complete with its own view of the
world and a special set of rules.

So, set your timeout at four and a half minutes and be happy. :slight_smile:

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Friday, September 22, 2006 7:32 AM
To: ntfsd redirect
Subject: [ntfsd] File system I/O not cancelable?

It appears that cached file system I/O which results in paging I/O
cannot be
canceled on Server 2003.

The IRP for the cached I/O is on the thread’s IRP list. Ntfs holds this
IRP, but does not set a cancel routine.

CcCopyRead generates a page fault to fill the cache. The IRP to satisfy
the
page fault goes to the volume driver (my driver), which sets a cancel
routine. However, this IRP has not been placed on the thread’s IRP
list.

So, if the volume driver takes a long time to process the IRP (for the
sake
of the argument, say, forever), and, for example, the user types
control-C
at his “type” command, the cached IRP cannot be canceled because it has
no
cancel routine, and the non-cached IRP cannot be canceled because it is
not
associated with the thread. And we continue to hang.

Is there anything that can be done to allow these I/O’s to be canceled?
Or
am I stuck timing out in the volume driver (with what, unfortunately,
needs
to be a relatively long timeout)?

At the last plugfest, Microsoft indicated that filters that hold IRPs
for
any substantial period should set a cancel routine. Will the physician
also
heal himself in this case?

Thanks,

  • Dan.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I haven’t tried Vista. We’re only interested in Server OSes. Haven’t tried
Longhorn Server either. We’re only interested in shipping OSes. I
specifically mentioned Server 2003 because that’s what I’m running on. But
isn’t it interesting that the most recent OS actually released is considered
legacy?

It wouldn’t actually be necessary for the file system to support
cancellation directly for everything to be ducky. All they would have had
to do was to put the paging IRP on the thread’s IRP list. On the subject of
your breakfast, I suppose I could have a filesystem filter insert the IRPs
in the queue. Is anything coming up yet?

I should actually be able to do a little better than 4.5 minutes on the
timeout, though.

Thanks,

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, September 22, 2006 8:45 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] File system I/O not cancelable?

Traditionally, none of the local file systems have supported I/O
cancellation directly (the term “directly” is of course because they do so
indirectly via the FsRtl routines for oplocks and directory change
notifications for example.) Presumably the idea is that these operations
should complete “quickly” and thus do not fall into the world in which the
hideous complexity of I/O cancellation becomes involved (hey, file systems
are bad enough, right?)

Given that Windows Server 2003 is a legacy system, and that this behavior is
consistent with the behavior since, oh, NT 3.1, I suspect you’ll have a
difficult time making a business case for changing this behavior.

I am curious - you restricted your comments to Windows Server 2003. Have you
tried this on Vista and found that it DOES support I/O cancellation (which
could be through the magic of file object queued IRPs of course.)

A quick think on this suggests there might be some hideous non-timeout
related solutions, but I stopped thinking about it quickly, realizing I
didn’t want to return my breakfast. :wink:

And of course NTFS wouldn’t be covered by the admonishment because it is not
a filter - it’s a file system, complete with its own view of the world and a
special set of rules.

So, set your timeout at four and a half minutes and be happy. :slight_smile:

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Dan Kyler
Sent: Friday, September 22, 2006 7:32 AM
To: ntfsd redirect
Subject: [ntfsd] File system I/O not cancelable?

It appears that cached file system I/O which results in paging I/O cannot be
canceled on Server 2003.

The IRP for the cached I/O is on the thread’s IRP list. Ntfs holds this
IRP, but does not set a cancel routine.

CcCopyRead generates a page fault to fill the cache. The IRP to satisfy the
page fault goes to the volume driver (my driver), which sets a cancel
routine. However, this IRP has not been placed on the thread’s IRP list.

So, if the volume driver takes a long time to process the IRP (for the sake
of the argument, say, forever), and, for example, the user types control-C
at his “type” command, the cached IRP cannot be canceled because it has no
cancel routine, and the non-cached IRP cannot be canceled because it is not
associated with the thread. And we continue to hang.

Is there anything that can be done to allow these I/O’s to be canceled? Or
am I stuck timing out in the volume driver (with what, unfortunately, needs
to be a relatively long timeout)?

At the last plugfest, Microsoft indicated that filters that hold IRPs for
any substantial period should set a cancel routine. Will the physician also
heal himself in this case?

Thanks,

  • Dan.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com