Confusing NTFS behavior (please help if you can)

NTFSD
1

Hi all,

I am trying to debug a user mode application that is writing some very large
files (> 50 GBytes) to an NTFS file system. These files are being written
as normal, nonoveralapped, buffered files.

The difficulty that I am having is that when I am writing two of these files
at once (along with a few other small files), I eventually get an error 183
(“Cannot create a file when that file already exists.”) from the WriteFile
call. This usually happens when the file reaches around 30 GBytes. I figured
this was a bad interpetation of some other kernel mode error, so I ran
FileMon on the system in question. It turns out that the error actually
coming back from NTFS is 0xc000009a (STATUS_INSUFFICIENT_RESOURCES). So it
appears that NTFS is running out of something it needs. As an obvious test,
I doubled the physical memory in system and 4x the size of the pagefile.
This had no effect on the problem, it still happens about the same place.

Here is an example from FileMon of the failure:

15889684 3:54:22.920 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf * 0xC000009A Offset: 29187456796 Length: 8688

Then I started looking at the FileMon output. Here I am finding 3 behaviors
that I don’t understand. I am hoping someone can enlighten me.

  1. All of the IO’s are being tried first as a FAST_IO, which is failing.
    That is fine, but then the IO is retried as an IRP, but the offset is
    different than the FAST_IO was?? Here are a few example lines from filemon.

15889658 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417583428 Length: 8688
15889659 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187387204 Length: 8688
15889660 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417592116 Length: 8776
15889661 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187395892 Length: 8776
15889662 3:54:22.889 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417600892 Length: 8688
15889663 3:54:22.889 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187404668 Length: 8688

as you can see, the write is attempted first as a fastio_write at offset
3417583428, when this fails, the IRP is issued at offset 29187387204. I
don’t understand this huge difference in offsets. Does any one understand
this?

  1. Here is the biggest mystery. Although I am seeing thousands of
    successful IRP_MJ_WRITE calls, I NEVER see any calls from the LazyWriter to
    these large files. For smaller files, I usually see something like this:

several cached writes:
15525500 3:48:30.733 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0_1.wav SUCCESS Offset: 437310766 Length: 1448

finally the uncached write:
15541757 3:48:41.905 PM System:4 IRP_MJ_WRITE* R:\WUtemp2\bigfile_cp0_1.wav
SUCCESS Offset: 437436416 Length: 65536

However, for the big files, I see thousands of cached writes and never any
uncached writes. Also, the FASTIO_WRITES are succeeding for these smaller
files. Any ideas??

  1. I am seeing a large number of uncached writes to an NTFS stream called
    R:$ConvertToNonresident. These seem to have some loose relationship to the
    writes taking place to the large file.

So I am generally wondering what is going on here. Why am I not seeing the
physical writes from the cache manager? It almost seems as if NTFS is
turning the cachedwrites into non-cached writes internally.

I would really appreciate any insight or ideas that anyone might have.

Thanks,

Don Edvalson

2

Hi Don,

I don’t know exactly what your problem is here, but here’s an
explanation for some of what you are seeing.

First, cached writes can occur by both the FastIO and IRP paths. The
idea behind the FastIO path is that this path is a streamlined path
which handles the “easy” cases for cached reads and writes. If the
request cannot be handled by this streamlined path, the file system
returns FALSE from its FastIO routine. The IO Manager will then reissue
the request via the IRP path so that the file system can handle the “not
easy” aspects about this cached IO request. Here are a few things that
can make writes “not easy”:
(1) file has byte range locks on portions of the file
(2) the cache manager is going to throttle the write request
(3) the cached write request is so large that the cache manager will
force the data to be flushed (today this limit greater than 64K)
(4) the file is marked as WRITE_THROUGH

My guess is that in your scenario, you are seeing the FastIO path fail
because writes are being throttled. This is completely expected when
copying a 30GB file. Clearly, we can do a memory copy (essentially what
a cached write entails) much faster than we can write the data to disk.
The cache manager uses throttling as a way to hold up cached requests so
that the system can flush the existing dirty data before allowing new
dirty data to be generated.

Second, the R:$ConvertToNonresident file object is very likely to be
the NTFS stream file object which NTFS created to back
R:\WUtemp2\bigfile_cp0_1.wav. You can verify this with a kernel
debugger - the FileObject->FsContext field should have the same value
for both FileObjects.

Third, the physical writes of the cached data could come from either the
cache manager (lazy writer threads) or the memory manager (mapped page
writer thread). In an IO trace, the easiest way to identify these
writes is looking at the process which generated them - both will come
from the system process instead of the copy application’s process. The
Irp->Flags allow you to further separate these two writers. Lazy writer
IRPs have the IRP_SYNCHRONOUS_PAGING_IO flag set (0x40), whereas mapped
page writer writes do not. I’m not sure if FileMon traces the
Irp->Flags, but I know that FileSpy does. FileSpy is one of our sample
filters in the IFS Kit and the binaries are part of the Resource Kit in
Windows 2000 and later.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don
Sent: Thursday, November 11, 2004 4:37 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Confusing NTFS behavior (please help if you can)

Hi all,

I am trying to debug a user mode application that is writing some very
large files (> 50 GBytes) to an NTFS file system. These files are being
written as normal, nonoveralapped, buffered files.

The difficulty that I am having is that when I am writing two of these
files at once (along with a few other small files), I eventually get an
error 183 (“Cannot create a file when that file already exists.”) from
the WriteFile call. This usually happens when the file reaches around 30
GBytes. I figured this was a bad interpetation of some other kernel mode
error, so I ran FileMon on the system in question. It turns out that the
error actually coming back from NTFS is 0xc000009a
(STATUS_INSUFFICIENT_RESOURCES). So it appears that NTFS is running out
of something it needs. As an obvious test, I doubled the physical memory
in system and 4x the size of the pagefile.
This had no effect on the problem, it still happens about the same
place.

Here is an example from FileMon of the failure:

15889684 3:54:22.920 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf * 0xC000009A Offset: 29187456796 Length: 8688

Then I started looking at the FileMon output. Here I am finding 3
behaviors
that I don’t understand. I am hoping someone can enlighten me.

  1. All of the IO’s are being tried first as a FAST_IO, which is
    failing.
    That is fine, but then the IO is retried as an IRP, but the offset is
    different than the FAST_IO was?? Here are a few example lines from
    filemon.

15889658 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417583428 Length: 8688
15889659 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187387204 Length: 8688
15889660 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417592116 Length: 8776
15889661 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187395892 Length: 8776
15889662 3:54:22.889 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417600892 Length: 8688
15889663 3:54:22.889 PM FileZilla Serve:1888 IRP_MJ_WRITE
R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187404668 Length: 8688

as you can see, the write is attempted first as a fastio_write at offset

3417583428, when this fails, the IRP is issued at offset 29187387204. I
don’t understand this huge difference in offsets. Does any one
understand
this?

  1. Here is the biggest mystery. Although I am seeing thousands of
    successful IRP_MJ_WRITE calls, I NEVER see any calls from the LazyWriter
    to
    these large files. For smaller files, I usually see something like this:

several cached writes:
15525500 3:48:30.733 PM FileZilla Serve:1888 FASTIO_WRITE
R:\WUtemp2\bigfile_cp0_1.wav SUCCESS Offset: 437310766 Length: 1448

finally the uncached write:
15541757 3:48:41.905 PM System:4 IRP_MJ_WRITE*
R:\WUtemp2\bigfile_cp0_1.wav
SUCCESS Offset: 437436416 Length: 65536

However, for the big files, I see thousands of cached writes and never
any
uncached writes. Also, the FASTIO_WRITES are succeeding for these
smaller
files. Any ideas??

  1. I am seeing a large number of uncached writes to an NTFS stream
    called
    R:$ConvertToNonresident. These seem to have some loose relationship to
    the
    writes taking place to the large file.

So I am generally wondering what is going on here. Why am I not seeing
the
physical writes from the cache manager? It almost seems as if NTFS is
turning the cachedwrites into non-cached writes internally.

I would really appreciate any insight or ideas that anyone might have.

Thanks,

Don Edvalson

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

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

3

Don,

Are the writes going across the network?

From: “Molly Brown”
>Reply-To: “Windows File Systems Devs Interest List”
>To: “Windows File Systems Devs Interest List”
>Subject: RE: [ntfsd] Confusing NTFS behavior (please help if you can)
>Date: Fri, 12 Nov 2004 09:12:30 -0800
>
>Hi Don,
>
>I don’t know exactly what your problem is here, but here’s an
>explanation for some of what you are seeing.
>
>First, cached writes can occur by both the FastIO and IRP paths. The
>idea behind the FastIO path is that this path is a streamlined path
>which handles the “easy” cases for cached reads and writes. If the
>request cannot be handled by this streamlined path, the file system
>returns FALSE from its FastIO routine. The IO Manager will then reissue
>the request via the IRP path so that the file system can handle the “not
>easy” aspects about this cached IO request. Here are a few things that
>can make writes “not easy”:
>(1) file has byte range locks on portions of the file
>(2) the cache manager is going to throttle the write request
>(3) the cached write request is so large that the cache manager will
>force the data to be flushed (today this limit greater than 64K)
>(4) the file is marked as WRITE_THROUGH
>
>My guess is that in your scenario, you are seeing the FastIO path fail
>because writes are being throttled. This is completely expected when
>copying a 30GB file. Clearly, we can do a memory copy (essentially what
>a cached write entails) much faster than we can write the data to disk.
>The cache manager uses throttling as a way to hold up cached requests so
>that the system can flush the existing dirty data before allowing new
>dirty data to be generated.
>
>Second, the R:$ConvertToNonresident file object is very likely to be
>the NTFS stream file object which NTFS created to back
>R:\WUtemp2\bigfile_cp0_1.wav. You can verify this with a kernel
>debugger - the FileObject->FsContext field should have the same value
>for both FileObjects.
>
>Third, the physical writes of the cached data could come from either the
>cache manager (lazy writer threads) or the memory manager (mapped page
>writer thread). In an IO trace, the easiest way to identify these
>writes is looking at the process which generated them - both will come
>from the system process instead of the copy application’s process. The
>Irp->Flags allow you to further separate these two writers. Lazy writer
>IRPs have the IRP_SYNCHRONOUS_PAGING_IO flag set (0x40), whereas mapped
>page writer writes do not. I’m not sure if FileMon traces the
>Irp->Flags, but I know that FileSpy does. FileSpy is one of our sample
>filters in the IFS Kit and the binaries are part of the Resource Kit in
>Windows 2000 and later.
>
>Regards,
>Molly Brown
>Microsoft Corporation
>
>This posting is provided “AS IS” with no warranties and confers no
>rights.
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Don
>Sent: Thursday, November 11, 2004 4:37 AM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] Confusing NTFS behavior (please help if you can)
>
>Hi all,
>
>I am trying to debug a user mode application that is writing some very
>large files (> 50 GBytes) to an NTFS file system. These files are being
>written as normal, nonoveralapped, buffered files.
>
>The difficulty that I am having is that when I am writing two of these
>files at once (along with a few other small files), I eventually get an
>error 183 (“Cannot create a file when that file already exists.”) from
>the WriteFile call. This usually happens when the file reaches around 30
>GBytes. I figured this was a bad interpetation of some other kernel mode
>error, so I ran FileMon on the system in question. It turns out that the
>error actually coming back from NTFS is 0xc000009a
>(STATUS_INSUFFICIENT_RESOURCES). So it appears that NTFS is running out
>of something it needs. As an obvious test, I doubled the physical memory
>in system and 4x the size of the pagefile.
>This had no effect on the problem, it still happens about the same
>place.
>
>Here is an example from FileMon of the failure:
>
>15889684 3:54:22.920 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf * 0xC000009A Offset: 29187456796 Length: 8688
>
>
>Then I started looking at the FileMon output. Here I am finding 3
>behaviors
>that I don’t understand. I am hoping someone can enlighten me.
>
>1. All of the IO’s are being tried first as a FAST_IO, which is
>failing.
>That is fine, but then the IO is retried as an IRP, but the offset is
>different than the FAST_IO was?? Here are a few example lines from
>filemon.
>
>15889658 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417583428 Length: 8688
>15889659 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187387204 Length: 8688
>15889660 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417592116 Length: 8776
>15889661 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187395892 Length: 8776
>15889662 3:54:22.889 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417600892 Length: 8688
>15889663 3:54:22.889 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187404668 Length: 8688
>
>as you can see, the write is attempted first as a fastio_write at offset
>
>3417583428, when this fails, the IRP is issued at offset 29187387204. I
>don’t understand this huge difference in offsets. Does any one
>understand
>this?
>
>2. Here is the biggest mystery. Although I am seeing thousands of
>successful IRP_MJ_WRITE calls, I NEVER see any calls from the LazyWriter
>to
>these large files. For smaller files, I usually see something like this:
>
>several cached writes:
>15525500 3:48:30.733 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0_1.wav SUCCESS Offset: 437310766 Length: 1448
>
>finally the uncached write:
>15541757 3:48:41.905 PM System:4 IRP_MJ_WRITE*
>R:\WUtemp2\bigfile_cp0_1.wav
>SUCCESS Offset: 437436416 Length: 65536
>
>However, for the big files, I see thousands of cached writes and never
>any
>uncached writes. Also, the FASTIO_WRITES are succeeding for these
>smaller
>files. Any ideas??
>
>3. I am seeing a large number of uncached writes to an NTFS stream
>called
>R:$ConvertToNonresident. These seem to have some loose relationship to
>the
>writes taking place to the large file.
>
>So I am generally wondering what is going on here. Why am I not seeing
>the
>physical writes from the cache manager? It almost seems as if NTFS is
>turning the cachedwrites into non-cached writes internally.
>
>I would really appreciate any insight or ideas that anyone might have.
>
>Thanks,
>
>Don Edvalson
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.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

4

Don,

You mentioned that you only see insufficient resources error when you
are writing two of these large files at the same time. This could be
caused because you are exceeding the number of extents supported by NTFS
for any given file. There is a limit to how many extents a file can
have.

When this fails have you checked to see how many extents the files have?
I am guessing this will be a huge number. This fragmentation would also
explain the large number of writes you are seeing to the
$ConvertToNonresident stream. This is the system writing out the extent
maps for the file.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Centis Biks
Sent: Friday, November 12, 2004 9:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Confusing NTFS behavior (please help if you can)

Don,

Are the writes going across the network?

From: “Molly Brown”
>Reply-To: “Windows File Systems Devs Interest List”

>To: “Windows File Systems Devs Interest List”
>Subject: RE: [ntfsd] Confusing NTFS behavior (please help if you can)
>Date: Fri, 12 Nov 2004 09:12:30 -0800
>
>Hi Don,
>
>I don’t know exactly what your problem is here, but here’s an
>explanation for some of what you are seeing.
>
>First, cached writes can occur by both the FastIO and IRP paths. The
>idea behind the FastIO path is that this path is a streamlined path
>which handles the “easy” cases for cached reads and writes. If the
>request cannot be handled by this streamlined path, the file system
>returns FALSE from its FastIO routine. The IO Manager will then
reissue
>the request via the IRP path so that the file system can handle the
“not
>easy” aspects about this cached IO request. Here are a few things that
>can make writes “not easy”:
>(1) file has byte range locks on portions of the file
>(2) the cache manager is going to throttle the write request
>(3) the cached write request is so large that the cache manager will
>force the data to be flushed (today this limit greater than 64K)
>(4) the file is marked as WRITE_THROUGH
>
>My guess is that in your scenario, you are seeing the FastIO path fail
>because writes are being throttled. This is completely expected when
>copying a 30GB file. Clearly, we can do a memory copy (essentially
what
>a cached write entails) much faster than we can write the data to disk.
>The cache manager uses throttling as a way to hold up cached requests
so
>that the system can flush the existing dirty data before allowing new
>dirty data to be generated.
>
>Second, the R:$ConvertToNonresident file object is very likely to be
>the NTFS stream file object which NTFS created to back
>R:\WUtemp2\bigfile_cp0_1.wav. You can verify this with a kernel
>debugger - the FileObject->FsContext field should have the same value
>for both FileObjects.
>
>Third, the physical writes of the cached data could come from either
the
>cache manager (lazy writer threads) or the memory manager (mapped page
>writer thread). In an IO trace, the easiest way to identify these
>writes is looking at the process which generated them - both will come
>from the system process instead of the copy application’s process. The
>Irp->Flags allow you to further separate these two writers. Lazy
writer
>IRPs have the IRP_SYNCHRONOUS_PAGING_IO flag set (0x40), whereas mapped
>page writer writes do not. I’m not sure if FileMon traces the
>Irp->Flags, but I know that FileSpy does. FileSpy is one of our sample
>filters in the IFS Kit and the binaries are part of the Resource Kit in
>Windows 2000 and later.
>
>Regards,
>Molly Brown
>Microsoft Corporation
>
>This posting is provided “AS IS” with no warranties and confers no
>rights.
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Don
>Sent: Thursday, November 11, 2004 4:37 AM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] Confusing NTFS behavior (please help if you can)
>
>Hi all,
>
>I am trying to debug a user mode application that is writing some very
>large files (> 50 GBytes) to an NTFS file system. These files are
being
>written as normal, nonoveralapped, buffered files.
>
>The difficulty that I am having is that when I am writing two of these
>files at once (along with a few other small files), I eventually get an
>error 183 (“Cannot create a file when that file already exists.”) from
>the WriteFile call. This usually happens when the file reaches around
30
>GBytes. I figured this was a bad interpetation of some other kernel
mode
>error, so I ran FileMon on the system in question. It turns out that
the
>error actually coming back from NTFS is 0xc000009a
>(STATUS_INSUFFICIENT_RESOURCES). So it appears that NTFS is running out
>of something it needs. As an obvious test, I doubled the physical
memory
>in system and 4x the size of the pagefile.
>This had no effect on the problem, it still happens about the same
>place.
>
>Here is an example from FileMon of the failure:
>
>15889684 3:54:22.920 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf * 0xC000009A Offset: 29187456796 Length:
8688
>
>
>Then I started looking at the FileMon output. Here I am finding 3
>behaviors
>that I don’t understand. I am hoping someone can enlighten me.
>
>1. All of the IO’s are being tried first as a FAST_IO, which is
>failing.
>That is fine, but then the IO is retried as an IRP, but the offset is
>different than the FAST_IO was?? Here are a few example lines from
>filemon.
>
>15889658 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417583428 Length: 8688
>15889659 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187387204 Length: 8688
>15889660 3:54:22.873 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417592116 Length: 8776
>15889661 3:54:22.873 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187395892 Length: 8776
>15889662 3:54:22.889 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset: 3417600892 Length: 8688
>15889663 3:54:22.889 PM FileZilla Serve:1888 IRP_MJ_WRITE
>R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset: 29187404668 Length: 8688
>
>as you can see, the write is attempted first as a fastio_write at
offset
>
>3417583428, when this fails, the IRP is issued at offset 29187387204. I
>don’t understand this huge difference in offsets. Does any one
>understand
>this?
>
>2. Here is the biggest mystery. Although I am seeing thousands of
>successful IRP_MJ_WRITE calls, I NEVER see any calls from the
LazyWriter
>to
>these large files. For smaller files, I usually see something like
this:
>
>several cached writes:
>15525500 3:48:30.733 PM FileZilla Serve:1888 FASTIO_WRITE
>R:\WUtemp2\bigfile_cp0_1.wav SUCCESS Offset: 437310766 Length: 1448
>
>finally the uncached write:
>15541757 3:48:41.905 PM System:4 IRP_MJ_WRITE*
>R:\WUtemp2\bigfile_cp0_1.wav
>SUCCESS Offset: 437436416 Length: 65536
>
>However, for the big files, I see thousands of cached writes and never
>any
>uncached writes. Also, the FASTIO_WRITES are succeeding for these
>smaller
>files. Any ideas??
>
>3. I am seeing a large number of uncached writes to an NTFS stream
>called
>R:$ConvertToNonresident. These seem to have some loose relationship to
>the
>writes taking place to the large file.
>
>So I am generally wondering what is going on here. Why am I not seeing
>the
>physical writes from the cache manager? It almost seems as if NTFS is
>turning the cachedwrites into non-cached writes internally.
>
>I would really appreciate any insight or ideas that anyone might have.
>
>Thanks,
>
>Don Edvalson
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as:
xxxxx@windows.microsoft.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

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

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

5

Don,
I think you have opened the files with caching
enabled. If you use FILE_FLAG_NO_BUFFERING and/or
FILE_FLAG_WRITE_THROUGH, you won’t see this problem.

Regards,
Janardhanan.R.

— Centis Biks wrote:

> Don,
>
> Are the writes going across the network?
>
> >From: “Molly Brown”
>
> >Reply-To: “Windows File Systems Devs Interest List”
>
> >To: “Windows File Systems Devs Interest List”
>
> >Subject: RE: [ntfsd] Confusing NTFS behavior
> (please help if you can)
> >Date: Fri, 12 Nov 2004 09:12:30 -0800
> >
> >Hi Don,
> >
> >I don’t know exactly what your problem is here, but
> here’s an
> >explanation for some of what you are seeing.
> >
> >First, cached writes can occur by both the FastIO
> and IRP paths. The
> >idea behind the FastIO path is that this path is a
> streamlined path
> >which handles the “easy” cases for cached reads and
> writes. If the
> >request cannot be handled by this streamlined path,
> the file system
> >returns FALSE from its FastIO routine. The IO
> Manager will then reissue
> >the request via the IRP path so that the file
> system can handle the “not
> >easy” aspects about this cached IO request. Here
> are a few things that
> >can make writes “not easy”:
> >(1) file has byte range locks on portions of the
> file
> >(2) the cache manager is going to throttle the
> write request
> >(3) the cached write request is so large that the
> cache manager will
> >force the data to be flushed (today this limit
> greater than 64K)
> >(4) the file is marked as WRITE_THROUGH
> >
> >My guess is that in your scenario, you are seeing
> the FastIO path fail
> >because writes are being throttled. This is
> completely expected when
> >copying a 30GB file. Clearly, we can do a memory
> copy (essentially what
> >a cached write entails) much faster than we can
> write the data to disk.
> >The cache manager uses throttling as a way to hold
> up cached requests so
> >that the system can flush the existing dirty data
> before allowing new
> >dirty data to be generated.
> >
> >Second, the R:$ConvertToNonresident file object is
> very likely to be
> >the NTFS stream file object which NTFS created to
> back
> >R:\WUtemp2\bigfile_cp0_1.wav. You can verify this
> with a kernel
> >debugger - the FileObject->FsContext field should
> have the same value
> >for both FileObjects.
> >
> >Third, the physical writes of the cached data could
> come from either the
> >cache manager (lazy writer threads) or the memory
> manager (mapped page
> >writer thread). In an IO trace, the easiest way to
> identify these
> >writes is looking at the process which generated
> them - both will come
> >from the system process instead of the copy
> application’s process. The
> >Irp->Flags allow you to further separate these two
> writers. Lazy writer
> >IRPs have the IRP_SYNCHRONOUS_PAGING_IO flag set
> (0x40), whereas mapped
> >page writer writes do not. I’m not sure if FileMon
> traces the
> >Irp->Flags, but I know that FileSpy does. FileSpy
> is one of our sample
> >filters in the IFS Kit and the binaries are part of
> the Resource Kit in
> >Windows 2000 and later.
> >
> >Regards,
> >Molly Brown
> >Microsoft Corporation
> >
> >This posting is provided “AS IS” with no warranties
> and confers no
> >rights.
> >
> >-----Original Message-----
> >From: xxxxx@lists.osr.com
> >[mailto:xxxxx@lists.osr.com] On Behalf
> Of Don
> >Sent: Thursday, November 11, 2004 4:37 AM
> >To: Windows File Systems Devs Interest List
> >Subject: [ntfsd] Confusing NTFS behavior (please
> help if you can)
> >
> >Hi all,
> >
> >I am trying to debug a user mode application that
> is writing some very
> >large files (> 50 GBytes) to an NTFS file system.
> These files are being
> >written as normal, nonoveralapped, buffered files.
> >
> >The difficulty that I am having is that when I am
> writing two of these
> >files at once (along with a few other small files),
> I eventually get an
> >error 183 (“Cannot create a file when that file
> already exists.”) from
> >the WriteFile call. This usually happens when the
> file reaches around 30
> >GBytes. I figured this was a bad interpetation of
> some other kernel mode
> >error, so I ran FileMon on the system in question.
> It turns out that the
> >error actually coming back from NTFS is 0xc000009a
> >(STATUS_INSUFFICIENT_RESOURCES). So it appears that
> NTFS is running out
> >of something it needs. As an obvious test, I
> doubled the physical memory
> >in system and 4x the size of the pagefile.
> >This had no effect on the problem, it still happens
> about the same
> >place.
> >
> >Here is an example from FileMon of the failure:
> >
> >15889684 3:54:22.920 PM FileZilla Serve:1888
> IRP_MJ_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf * 0xC000009A Offset:
> 29187456796 Length: 8688
> >
> >
> >Then I started looking at the FileMon output. Here
> I am finding 3
> >behaviors
> >that I don’t understand. I am hoping someone can
> enlighten me.
> >
> >1. All of the IO’s are being tried first as a
> FAST_IO, which is
> >failing.
> >That is fine, but then the IO is retried as an IRP,
> but the offset is
> >different than the FAST_IO was?? Here are a few
> example lines from
> >filemon.
> >
> >15889658 3:54:22.873 PM FileZilla Serve:1888
> FASTIO_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset:
> 3417583428 Length: 8688
> >15889659 3:54:22.873 PM FileZilla Serve:1888
> IRP_MJ_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset:
> 29187387204 Length: 8688
> >15889660 3:54:22.873 PM FileZilla Serve:1888
> FASTIO_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset:
> 3417592116 Length: 8776
> >15889661 3:54:22.873 PM FileZilla Serve:1888
> IRP_MJ_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset:
> 29187395892 Length: 8776
> >15889662 3:54:22.889 PM FileZilla Serve:1888
> FASTIO_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf FAILURE Offset:
> 3417600892 Length: 8688
> >15889663 3:54:22.889 PM FileZilla Serve:1888
> IRP_MJ_WRITE
> >R:\WUtemp2\bigfile_cp0.mxf SUCCESS Offset:
> 29187404668 Length: 8688
> >
> >as you can see, the write is attempted first as a
> fastio_write at offset
> >
> >3417583428, when this fails, the IRP is issued at
> offset 29187387204. I
> >don’t understand this huge difference in offsets.
> Does any one
> >understand
> >this?
> >
> >2. Here is the biggest mystery. Although I am
> seeing thousands of
> >successful IRP_MJ_WRITE calls, I NEVER see any
> calls from the LazyWriter
> >to
>
=== message truncated ===

__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com