Note that it is important not to confuse “this is the way it is done
currently” with “this is the only way to do it”. A frequent problem with
file system filter drivers is that they do not implement to support the
range of options that are possible given the API.
For example, there is *nothing* that requires directory enumerations be done
synchronously. In fact, if I were going to implement a network file server I
might easily envision implementing directory enumeration asynchronously -
that’s how you get better performance. Will it give your file system filter
driver fits? If it does, and the OS works when your filter is not installed
it is your fault things break.
Better to design understanding the API than it is to understand the current
usage pattern.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class in Menlo Park, CA
September 8, 2003!
-----Original Message-----
From: Nick Ryan [mailto:xxxxx@nryan.com]
Sent: Friday, August 29, 2003 1:37 PM
To: File Systems Developers
Subject: [ntfsd] Re: nis2003 and status pending
The docs on IoIsOperationSynchronous list the reasons why a given
request would be synchronous or not. As it mentions, some requests are
always synchronous, such as most of the non-read/write APIs:
"If the IRP requests asynchronous paging I/O, the operation is
asynchronous, even if one of the other conditions is true.
If the IRP requests synchronous paging I/O, the operation is synchronous.
If the file object was opened for synchronous I/O, the operation is
synchronous.
If the IRP_SYNCHRONOUS_API flag is set in the IRP, the operation is
synchronous. This flag is set for operations, such as
ZwQueryInformationFile and ZwSetInformationFile, that are always
synchronous, even when performed on a file object that was opened for
asynchronous I/O.
If none of the above conditions is true, the operation is asynchronous."
Ampsi wrote:
oh, guess i have got it wrong, thanks. i thought directory control is
asynchronous… so i am handling it using the asynchronously method.
what other requests are synchronous? i know create, cleanup, close are…
Ampsi
----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Friday, August 29, 2003 02:13
> Subject: [ntfsd] Re: nis2003 and status pending
>
>
> Yes. That’s what your doing, isn’t it - post-processing directory
> control requests? Since IRP_MN_QUERY_DIRECTORY requests are by nature
> synchronous, you gain nothing by pending them.
>
> Ampsi wrote:
>
>
>>i am doing this in create. i thought this method is used when the
>>processsing needs to be performed in the original thread context and after
>>the irp returns from the lower file system?
>>
>>Ampsi
>>
>>----- Original Message -----
>>From: “Nick Ryan”
>>Newsgroups: ntfsd
>>To: “File Systems Developers”
>>Sent: Thursday, August 28, 2003 02:36
>>Subject: [ntfsd] Re: nis2003 and status pending
>>
>>
>>What you need to do is set a completion routine and give it an event
>>pointer, then wait on this event in your dispatch routine after sending
>>down the IRP. The completion routine just sets the event and returns
>>STATUS_MORE_PROCESSING_REQUIRED. The dispatch routine now has control
>>and can perform any post-processing required.
>>
>>Ho Mun Chuen wrote:
>>
>>
>>
>>>hi,
>>>
>>>i have always been using worker threads to perform post processing on
>>>directory control requests to modify the information returned, and it has
>>>been no problem.
>>>
>>>what i do is to call IoMarkIrpPending on the irp and return
>>
>>STATUS_PENDING,
>>
>>
>>>in the directory control dispatch routine. then in the completion
routine,
>>>queue the irp to a worker thread using a workitem and return
>>>STATUS_MORE_PROCESSING_REQUIRED. when the worker thread finishes, it will
>>>call IoCompleteRequest.
>>>
>>>however, with NIS2003, it seems not able to handle the STATUS_PENDING
>>
>>well,
>>
>>
>>>as it will cause my system to hang when its apps try to start.
>>>
>>>now what i do is not to call IoMarkIrpPending and return STATUS_PENDING.
>>>instead, i just call IoCallDriver and return the status as per normal.
>>
>>then
>>
>>
>>>in the completion, i still queue the irp to a worker thread using a
>>
>>workitem
>>
>>
>>>but now i make it wait on a event. the event will be triggered when the
>>>worker thread finishes. then the completion routine will return
>>>STATUS_SUCCESS.
>>>
>>>my questions are:
>>>
>>>1) is there anything wrong with what i am doing originally?
>>>2) will there be anything wrong with what i am doing now?
>>>3) if both methods are ok, why is the first method usually the one that i
>>>see being used and not the second?
>>>4) if my original way is not wrong, then is NIS2003 not handling it
>>>properly? i don’t see this problem with NIS2001.
>>>
>>>thanks!!
>>>
>>>Ampsi
>>>
>>>
>>>
>>>
>>
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
–
Nick Ryan (MVP for DDK)
—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com