I am storing the full filename path for every StreamHandleContext.
Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION into
my own buffer which is allocated with ExAllocatePool.
Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION struct
around and save the copy, allocate, and free CPU cycles? There are many
UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point to one
buffer?
Is it ok to put off calling FltReleaseFileNameInformation until the stream
handle context cleanup callbacks?
You can hang onto the filename reference for as long as you like - even
after the file is closed and it’s contexts released. It is an independently
(from stream contexts) maintained object and will not be freed until it’s
ref count goes to 0.
/ted
-----Original Message-----
From: Mark Hahn [mailto:xxxxx@hahnca.com]
Sent: Wednesday, May 11, 2005 8:51 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
I am storing the full filename path for every StreamHandleContext.
Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION into
my own buffer which is allocated with ExAllocatePool.
Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION struct
around and save the copy, allocate, and free CPU cycles? There are many
UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point to one
buffer?
Is it ok to put off calling FltReleaseFileNameInformation until the stream
handle context cleanup callbacks?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same buffer.
Keep in mind, however, that while you have the name information referenced,
the name won’t change. After a rename, you’ll have stale information, and
you must detect this and handle it. Of course, the same is true allocating
your own buffers.
At 05:51 PM 5/11/2005 -0700, you wrote:
I am storing the full filename path for every StreamHandleContext.
Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION into
my own buffer which is allocated with ExAllocatePool.
Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION struct
around and save the copy, allocate, and free CPU cycles? There are many
UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point to one
buffer?
Is it ok to put off calling FltReleaseFileNameInformation until the stream
handle context cleanup callbacks?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks to both of you. I will switch it over.
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
> buffer.
>
> Keep in mind, however, that while you have the name information
> referenced, the name won’t change. After a rename, you’ll have stale
> information, and you must detect this and handle it. Of course, the same
> is true allocating your own buffers.
>
> - Dan.
>
> At 05:51 PM 5/11/2005 -0700, you wrote:
>>I am storing the full filename path for every StreamHandleContext.
>>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION into
>>my own buffer which is allocated with ExAllocatePool.
>>
>>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
>>struct
>>around and save the copy, allocate, and free CPU cycles? There are many
>>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point to
>>one
>>buffer?
>>
>>Is it ok to put off calling FltReleaseFileNameInformation until the stream
>>handle context cleanup callbacks?
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
I should warn anyone following this thread that FLT_FILE_NAME_INFORMATION is
allocated in paged memory. This is causing me a serious problem which may
cause me to go back to copying each one.
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
> buffer.
>
> Keep in mind, however, that while you have the name information
> referenced, the name won’t change. After a rename, you’ll have stale
> information, and you must detect this and handle it. Of course, the same
> is true allocating your own buffers.
>
> - Dan.
>
> At 05:51 PM 5/11/2005 -0700, you wrote:
>>I am storing the full filename path for every StreamHandleContext.
>>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION into
>>my own buffer which is allocated with ExAllocatePool.
>>
>>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
>>struct
>>around and save the copy, allocate, and free CPU cycles? There are many
>>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point to
>>one
>>buffer?
>>
>>Is it ok to put off calling FltReleaseFileNameInformation until the stream
>>handle context cleanup callbacks?
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Strings are in general allocated from paged pool due to their
potentially large size and the scarcity of non-paged pool for use in
drivers.
If you were allocating from non-paged pool I would suggest you are
analyzing your strings in paths where you should not. Be VERY cautious
because many of the string routines are themselves pageable and cannot
be used safely at elevated IRQL.
Regards,
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 Mark Hahn
Sent: Thursday, May 12, 2005 9:48 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
I should warn anyone following this thread that
FLT_FILE_NAME_INFORMATION is
allocated in paged memory. This is causing me a serious problem which
may
cause me to go back to copying each one.
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
> buffer.
>
> Keep in mind, however, that while you have the name information
> referenced, the name won’t change. After a rename, you’ll have stale
> information, and you must detect this and handle it. Of course, the
same
> is true allocating your own buffers.
>
> - Dan.
>
> At 05:51 PM 5/11/2005 -0700, you wrote:
>>I am storing the full filename path for every StreamHandleContext.
>>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION
into
>>my own buffer which is allocated with ExAllocatePool.
>>
>>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
>>struct
>>around and save the copy, allocate, and free CPU cycles? There are
many
>>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point
to
>>one
>>buffer?
>>
>>Is it ok to put off calling FltReleaseFileNameInformation until the
stream
>>handle context cleanup callbacks?
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.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: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I’m currently trying to reduce my non-paged pool usage, which I why I
originally asked this question. Can you tell me if one of the symptoms of
too much non-paged pool usage would be for the IOStress tool to put out
messages like this and run very slowly?
RTL: Enter Critical Section Timeout (1620 secs) 0
RTL: Pid.Tid 5fc.4b4, owner tid 5ac Critical Section 007340E0 -
ContentionCount == 4
RTL: Re-Waiting
The screen goes black on the target PC and I get hundreds of these “Enter
Critical Section Timeout” messages in WinDbg. There is nothing else to tell
me what is going on since the black screen hides the progress indicator in
the upper right corner of the screen. I made sure the screen blanker was
turned off before starting the test.
Also, every once in a while I get a breakpoint in an unknown module:
Break instruction exception - code 80000003 (first chance)
Unknown_Module_7c900000+0x1230:
001b:7c901230 cc int 3
kd> g
Can anyone give me a clue to what’s going on?
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Strings are in general allocated from paged pool due to their
potentially large size and the scarcity of non-paged pool for use in
drivers.
If you were allocating from non-paged pool I would suggest you are
analyzing your strings in paths where you should not. Be VERY cautious
because many of the string routines are themselves pageable and cannot
be used safely at elevated IRQL.
Regards,
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 Mark Hahn
Sent: Thursday, May 12, 2005 9:48 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
I should warn anyone following this thread that
FLT_FILE_NAME_INFORMATION is
allocated in paged memory. This is causing me a serious problem which
may
cause me to go back to copying each one.
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
> buffer.
>
> Keep in mind, however, that while you have the name information
> referenced, the name won’t change. After a rename, you’ll have stale
> information, and you must detect this and handle it. Of course, the
same
> is true allocating your own buffers.
>
> - Dan.
>
> At 05:51 PM 5/11/2005 -0700, you wrote:
>>I am storing the full filename path for every StreamHandleContext.
>>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION
into
>>my own buffer which is allocated with ExAllocatePool.
>>
>>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
>>struct
>>around and save the copy, allocate, and free CPU cycles? There are
many
>>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point
to
>>one
>>buffer?
>>
>>Is it ok to put off calling FltReleaseFileNameInformation until the
stream
>>handle context cleanup callbacks?
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.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: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I’m currently trying to reduce my non-paged pool usage, which I why I
originally asked this question. Can you tell me if one of the symptoms of
too much non-paged pool usage would be for the IOStress tool to put out
messages like this and run very slowly?
RTL: Enter Critical Section Timeout (1620 secs) 0
RTL: Pid.Tid 5fc.4b4, owner tid 5ac Critical Section 007340E0 -
ContentionCount == 4
RTL: Re-Waiting
The screen goes black on the target PC and I get hundreds of these “Enter
Critical Section Timeout” messages in WinDbg. There is nothing else to tell
me what is going on since the black screen hides the progress indicator in
the upper right corner of the screen. I made sure the screen blanker was
turned off before starting the test.
Also, every once in a while I get a breakpoint in an unknown module:
Break instruction exception - code 80000003 (first chance)
Unknown_Module_7c900000+0x1230:
001b:7c901230 cc int 3
kd> g
Can anyone give me a clue to what’s going on?
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Strings are in general allocated from paged pool due to their
potentially large size and the scarcity of non-paged pool for use in
drivers.
If you were allocating from non-paged pool I would suggest you are
analyzing your strings in paths where you should not. Be VERY cautious
because many of the string routines are themselves pageable and cannot
be used safely at elevated IRQL.
Regards,
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 Mark Hahn
Sent: Thursday, May 12, 2005 9:48 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
I should warn anyone following this thread that
FLT_FILE_NAME_INFORMATION is
allocated in paged memory. This is causing me a serious problem which
may
cause me to go back to copying each one.
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
> buffer.
>
> Keep in mind, however, that while you have the name information
> referenced, the name won’t change. After a rename, you’ll have stale
> information, and you must detect this and handle it. Of course, the
same
> is true allocating your own buffers.
>
> - Dan.
>
> At 05:51 PM 5/11/2005 -0700, you wrote:
>>I am storing the full filename path for every StreamHandleContext.
>>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION
into
>>my own buffer which is allocated with ExAllocatePool.
>>
>>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
>>struct
>>around and save the copy, allocate, and free CPU cycles? There are
many
>>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point
to
>>one
>>buffer?
>>
>>Is it ok to put off calling FltReleaseFileNameInformation until the
stream
>>handle context cleanup callbacks?
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@privtek.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: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Can be some issues in IOStress.
I have hit NPP exhaustion situation in my code once. It just starts to fail
most syscalls with STATUS_INSUFFICIENT_RESOURCES.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Mark Hahn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, May 13, 2005 11:29 PM
Subject: Re:[ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
> I’m currently trying to reduce my non-paged pool usage, which I why I
> originally asked this question. Can you tell me if one of the symptoms of
> too much non-paged pool usage would be for the IOStress tool to put out
> messages like this and run very slowly?
>
> RTL: Enter Critical Section Timeout (1620 secs) 0
> RTL: Pid.Tid 5fc.4b4, owner tid 5ac Critical Section 007340E0 -
> ContentionCount == 4
> RTL: Re-Waiting
>
> The screen goes black on the target PC and I get hundreds of these “Enter
> Critical Section Timeout” messages in WinDbg. There is nothing else to tell
> me what is going on since the black screen hides the progress indicator in
> the upper right corner of the screen. I made sure the screen blanker was
> turned off before starting the test.
>
> Also, every once in a while I get a breakpoint in an unknown module:
>
> Break instruction exception - code 80000003 (first chance)
> Unknown_Module_7c900000+0x1230:
> 001b:7c901230 cc int 3
> kd> g
>
> Can anyone give me a clue to what’s going on?
>
> -------------------------------------------
>
> “Tony Mason” wrote in message news:xxxxx@ntfsd…
> Strings are in general allocated from paged pool due to their
> potentially large size and the scarcity of non-paged pool for use in
> drivers.
>
> If you were allocating from non-paged pool I would suggest you are
> analyzing your strings in paths where you should not. Be VERY cautious
> because many of the string routines are themselves pageable and cannot
> be used safely at elevated IRQL.
>
> Regards,
>
> 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 Mark Hahn
> Sent: Thursday, May 12, 2005 9:48 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] Keeping FLT_FILE_NAME_INFORMATION versus copying?
>
> I should warn anyone following this thread that
> FLT_FILE_NAME_INFORMATION is
> allocated in paged memory. This is causing me a serious problem which
> may
> cause me to go back to copying each one.
>
> “Dan Kyler” wrote in message news:xxxxx@ntfsd…
> > All the UNICODE_STRINGS in FLT_FILE_NAME_INFORMATION point to the same
>
> > buffer.
> >
> > Keep in mind, however, that while you have the name information
> > referenced, the name won’t change. After a rename, you’ll have stale
> > information, and you must detect this and handle it. Of course, the
> same
> > is true allocating your own buffers.
> >
> > - Dan.
> >
> > At 05:51 PM 5/11/2005 -0700, you wrote:
> >>I am storing the full filename path for every StreamHandleContext.
> >>Currently I am copying the file name out of FLT_FILE_NAME_INFORMATION
> into
> >>my own buffer which is allocated with ExAllocatePool.
> >>
> >>Would it be better to just keep the entire FLT_FILE_NAME_INFORMATION
> >>struct
> >>around and save the copy, allocate, and free CPU cycles? There are
> many
> >>UNICODE strings in FLT_FILE_NAME_INFORMATION but I do they all point
> to
> >>one
> >>buffer?
> >>
> >>Is it ok to put off calling FltReleaseFileNameInformation until the
> stream
> >>handle context cleanup callbacks?
> >>
> >>
> >>
> >>—
> >>Questions? First check the IFS FAQ at
> >>https://www.osronline.com/article.cfm?id=17
> >>
> >>You are currently subscribed to ntfsd as: xxxxx@privtek.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: 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: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com