How to do page write?

Mark_Hahn · May 18, 2005, 2:48pm

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

Mark_Hahn · May 18, 2005, 5:44pm

I accidently copied that code from an old version. Here is the correct
code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
&initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );

status = FltWriteFile( gOutVolInstance, gOutputFileObject, (PLARGE_INTEGER)
&gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr, FLTFL_IO_OPERATION_NON_CACHED,
&bytesWritten, CpsPageWriteCallback, PagePtr );

OSR_Community_User · May 18, 2005, 5:59pm

Mark:

(PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If gCurOutputFilePos
really is an int32, then it will interpret it as a pointer to an int64,
which could be very, very large. I doubt if that was your intent?

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 5:44 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to do page write?

I accidently copied that code from an old version. Here is the correct
code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
&initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );

status = FltWriteFile( gOutVolInstance, gOutputFileObject, (PLARGE_INTEGER)
&gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr, FLTFL_IO_OPERATION_NON_CACHED,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

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

OSR_Community_User · May 18, 2005, 6:13pm

Paging IO never extends EOF. You just created the file so its size is 0.
At least you need to explicitly extend file before writing out data using
Paging IO.

There are other potential problems using paging IO:

cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.
depending on TopLevelIrp it may skip writing data beyond valid data length

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 11:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to do page write?

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

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

Mark_Hahn · May 18, 2005, 6:25pm

gCurOutputFilePos is actually a ULONGLONG so it should work fine. I hate
LARGE_INTEGER. It is left over from old compilers.

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> (PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If gCurOutputFilePos
> really is an int32, then it will interpret it as a pointer to an int64,
> which could be very, very large. I doubt if that was your intent?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Wednesday, May 18, 2005 5:44 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] How to do page write?
>
> I accidently copied that code from an old version. Here is the correct
> code:
>
> InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
> OBJ_KERNEL_HANDLE, NULL, NULL );
>
> status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
> FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
> &initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
> FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );
>
> status = FltWriteFile( gOutVolInstance, gOutputFileObject,
> (PLARGE_INTEGER)
> &gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr, FLTFL_IO_OPERATION_NON_CACHED,
> &bytesWritten, CpsPageWriteCallback, PagePtr );
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

Mark_Hahn · May 18, 2005, 6:33pm

> Paging IO never extends EOF. You just created the file so its size is 0.

At least you need to explicitly extend file before writing out data using
Paging IO.

If you saw the corrected code you’ll see that I specified an initial file
allocation size which happens to be the max size of my file. Doesn’t this
mean it won’t have to extend the file, or is allocation size different from
file size? How do I “explicitly extend” the file?

cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.

I don’t understand this. I am not using the cache at all for this file. I
am using the flags FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING
and allocating my own aligned memory.

depending on TopLevelIrp it may skip writing data beyond valid data length

This boils down to the same issue as your first point, right? If I make
sure the length is correct when I start this shouldn’t be an issue.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
Paging IO never extends EOF. You just created the file so its size is 0.
At least you need to explicitly extend file before writing out data using
Paging IO.

There are other potential problems using paging IO:
- cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.
- depending on TopLevelIrp it may skip writing data beyond valid data length

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 11:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to do page write?

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

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

OSR_Community_User · May 18, 2005, 6:42pm

Mark:

The docs say that FILE_NO_INTERMEDIATE_BUFFERING “is incompatible with the
DesiredAccess FILE_APPEND_DATA flag”. I’m not sure of the implications of
that in your context since you set FLTFL_IO_OPERATION_NON_CACHED in the
write, but maybe it could result in unpredictable behavior (which is what
you’re seeing).

I presume you’re getting success back from FltCreateFile and FltWriteFile?

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 6:25 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to do page write?

gCurOutputFilePos is actually a ULONGLONG so it should work fine. I hate
LARGE_INTEGER. It is left over from old compilers.

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> (PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If gCurOutputFilePos
> really is an int32, then it will interpret it as a pointer to an int64,
> which could be very, very large. I doubt if that was your intent?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Wednesday, May 18, 2005 5:44 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] How to do page write?
>
> I accidently copied that code from an old version. Here is the correct
> code:
>
> InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
> OBJ_KERNEL_HANDLE, NULL, NULL );
>
> status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
> FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
> &initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
> FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );
>
> status = FltWriteFile( gOutVolInstance, gOutputFileObject,
> (PLARGE_INTEGER)
> &gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr, FLTFL_IO_OPERATION_NON_CACHED,
> &bytesWritten, CpsPageWriteCallback, PagePtr );
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> 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@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mark_Hahn · May 18, 2005, 6:58pm

> The docs say that FILE_NO_INTERMEDIATE_BUFFERING "is incompatible with the

DesiredAccess FILE_APPEND_DATA flag

Thanks. I didn’t notice that. I’ll try removing it. It does seem
incorrect to use FILE_APPEND_DATA if I’m trying to pre-allocate a file and
then write to it.

I am also trying to figure out how to “explcitly extend” the file at
creation instead of just pre-allocating space (if there is any difference).

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> The docs say that FILE_NO_INTERMEDIATE_BUFFERING “is incompatible with the
> DesiredAccess FILE_APPEND_DATA flag”. I’m not sure of the implications of
> that in your context since you set FLTFL_IO_OPERATION_NON_CACHED in the
> write, but maybe it could result in unpredictable behavior (which is what
> you’re seeing).
>
> I presume you’re getting success back from FltCreateFile and FltWriteFile?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Wednesday, May 18, 2005 6:25 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] How to do page write?
>
> gCurOutputFilePos is actually a ULONGLONG so it should work fine. I hate
> LARGE_INTEGER. It is left over from old compilers.
>
> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>> Mark:
>>
>> (PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If
>> gCurOutputFilePos
>> really is an int32, then it will interpret it as a pointer to an int64,
>> which could be very, very large. I doubt if that was your intent?
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
>> Sent: Wednesday, May 18, 2005 5:44 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] How to do page write?
>>
>> I accidently copied that code from an old version. Here is the correct
>> code:
>>
>> InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
>> OBJ_KERNEL_HANDLE, NULL, NULL );
>>
>> status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
>> FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
>> &initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
>> FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );
>>
>> status = FltWriteFile( gOutVolInstance, gOutputFileObject,
>> (PLARGE_INTEGER)
>> &gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr,
>> FLTFL_IO_OPERATION_NON_CACHED,
>> &bytesWritten, CpsPageWriteCallback, PagePtr );
>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OSR_Community_User · May 18, 2005, 7:03pm

>If you saw the corrected code you’ll see that I specified an initial file

allocation size which happens to be the max size of my file. Doesn’t this
mean it won’t have to extend the file, or is allocation size different from
file size? How do I “explicitly extend” the file?

You should not mix allocation size (space allocated on the disk) and logical
file size (number of bytes you can read from the file). There is
IRP_MJ_SET_INFORMATION/FileEndOfFileInformation which allows to explicitly
set EOF. Normal (not paging IO) writes extends EOF when writing beyond EOF;
paging IO doesn’t extend EOF and since no data was written it returns 0 in
the information field.

> cache consistency: during paging write FS doesn’t flush the cache so stale

> data from cache may overwrite your data when cache is flushed.

I don’t understand this. I am not using the cache at all for this file. I
am using the flags FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING

and allocating my own aligned memory.

If you are the only one who uses the file - then no data will be in the
cache. If somebody else (antivirus or indexing service for example) opens the
file concurrently some data may end up in the cache.

> depending on TopLevelIrp it may skip writing data beyond valid data length

This boils down to the same issue as your first point, right? If I make
sure the length is correct when I start this shouldn’t be an issue.

Basically file systems maintain 3 different lengths for a file - Allocation
length, End of file and valid data length. They do have different values and
are changed at differnt time.

Alexei.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
Paging IO never extends EOF. You just created the file so its size is 0.
At least you need to explicitly extend file before writing out data using
Paging IO.

There are other potential problems using paging IO:
- cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.
- depending on TopLevelIrp it may skip writing data beyond valid data length

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 11:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to do page write?

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

You are currently subscribed to ntfsd as: xxxxx@vmware.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@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · May 18, 2005, 7:09pm

Mark:

Just setting the EOF to some arbitrary value won’t actually extend the file
(ala VMS ) – it will result in a sparse file with a big EOF.

I don’t know of any alternative other than just write all the data blocks to
the file when you create it.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 6:58 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to do page write?

> The docs say that FILE_NO_INTERMEDIATE_BUFFERING "is incompatible with the

> DesiredAccess FILE_APPEND_DATA flag

Thanks. I didn’t notice that. I’ll try removing it. It does seem
incorrect to use FILE_APPEND_DATA if I’m trying to pre-allocate a file and
then write to it.

I am also trying to figure out how to “explcitly extend” the file at
creation instead of just pre-allocating space (if there is any difference).

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> The docs say that FILE_NO_INTERMEDIATE_BUFFERING “is incompatible with the
> DesiredAccess FILE_APPEND_DATA flag”. I’m not sure of the implications of
> that in your context since you set FLTFL_IO_OPERATION_NON_CACHED in the
> write, but maybe it could result in unpredictable behavior (which is what
> you’re seeing).
>
> I presume you’re getting success back from FltCreateFile and FltWriteFile?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Wednesday, May 18, 2005 6:25 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] How to do page write?
>
> gCurOutputFilePos is actually a ULONGLONG so it should work fine. I hate
> LARGE_INTEGER. It is left over from old compilers.
>
> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>> Mark:
>>
>> (PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If
>> gCurOutputFilePos
>> really is an int32, then it will interpret it as a pointer to an int64,
>> which could be very, very large. I doubt if that was your intent?
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
>> Sent: Wednesday, May 18, 2005 5:44 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] How to do page write?
>>
>> I accidently copied that code from an old version. Here is the correct
>> code:
>>
>> InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
>> OBJ_KERNEL_HANDLE, NULL, NULL );
>>
>> status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
>> FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
>> &initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
>> FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );
>>
>> status = FltWriteFile( gOutVolInstance, gOutputFileObject,
>> (PLARGE_INTEGER)
>> &gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr,
>> FLTFL_IO_OPERATION_NON_CACHED,
>> &bytesWritten, CpsPageWriteCallback, PagePtr );
>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> 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@comcast.net
> 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@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mark_Hahn · May 18, 2005, 9:16pm

Thanks for your clear explanations. I’ll try using setinfo to set EOF and
end-of-valid-data before I begin writiing to it.

Do you think that my overall goal of acheiving higher priorities for my
writes will happen if I get paging writes to work? Am I doing all this for
nothing?

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
>If you saw the corrected code you’ll see that I specified an initial file
>allocation size which happens to be the max size of my file. Doesn’t this
>mean it won’t have to extend the file, or is allocation size different from
>file size? How do I “explicitly extend” the file?

You should not mix allocation size (space allocated on the disk) and logical
file size (number of bytes you can read from the file). There is
IRP_MJ_SET_INFORMATION/FileEndOfFileInformation which allows to explicitly
set EOF. Normal (not paging IO) writes extends EOF when writing beyond EOF;
paging IO doesn’t extend EOF and since no data was written it returns 0 in
the information field.

>> cache consistency: during paging write FS doesn’t flush the cache so
>> stale

>> data from cache may overwrite your data when cache is flushed.

>I don’t understand this. I am not using the cache at all for this file. I
>am using the flags FLTFL_IO_OPERATION_NON_CACHED |
>FLTFL_IO_OPERATION_PAGING

>and allocating my own aligned memory.

If you are the only one who uses the file - then no data will be in the
cache. If somebody else (antivirus or indexing service for example) opens
the
file concurrently some data may end up in the cache.

>> depending on TopLevelIrp it may skip writing data beyond valid data
>> length
>
>This boils down to the same issue as your first point, right? If I make
>sure the length is correct when I start this shouldn’t be an issue.

Basically file systems maintain 3 different lengths for a file - Allocation
length, End of file and valid data length. They do have different values and
are changed at differnt time.

Alexei.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
Paging IO never extends EOF. You just created the file so its size is 0.
At least you need to explicitly extend file before writing out data using
Paging IO.

There are other potential problems using paging IO:
- cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.
- depending on TopLevelIrp it may skip writing data beyond valid data length

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 11:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to do page write?

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

You are currently subscribed to ntfsd as: xxxxx@vmware.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@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mark_Hahn · May 18, 2005, 9:18pm

Maybe the paging write will still work even if EOF is just set with a
setinfo call.

How does the mm initialize a paging file? (I’ll google on that question).

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> Just setting the EOF to some arbitrary value won’t actually extend the
> file
> (ala VMS ) – it will result in a sparse file with a big EOF.
>
> I don’t know of any alternative other than just write all the data blocks
> to
> the file when you create it.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Wednesday, May 18, 2005 6:58 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] How to do page write?
>
>> The docs say that FILE_NO_INTERMEDIATE_BUFFERING "is incompatible with
>> the
>
>> DesiredAccess FILE_APPEND_DATA flag
>
> Thanks. I didn’t notice that. I’ll try removing it. It does seem
> incorrect to use FILE_APPEND_DATA if I’m trying to pre-allocate a file and
> then write to it.
>
> I am also trying to figure out how to “explcitly extend” the file at
> creation instead of just pre-allocating space (if there is any
> difference).
>
> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>> Mark:
>>
>> The docs say that FILE_NO_INTERMEDIATE_BUFFERING “is incompatible with
>> the
>> DesiredAccess FILE_APPEND_DATA flag”. I’m not sure of the implications
>> of
>> that in your context since you set FLTFL_IO_OPERATION_NON_CACHED in the
>> write, but maybe it could result in unpredictable behavior (which is what
>> you’re seeing).
>>
>> I presume you’re getting success back from FltCreateFile and
>> FltWriteFile?
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
>> Sent: Wednesday, May 18, 2005 6:25 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] How to do page write?
>>
>> gCurOutputFilePos is actually a ULONGLONG so it should work fine. I hate
>> LARGE_INTEGER. It is left over from old compilers.
>>
>> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>>> Mark:
>>>
>>> (PLARGE_INTEGER)&gCurOutputFilePos looks suspicious. If
>>> gCurOutputFilePos
>>> really is an int32, then it will interpret it as a pointer to an int64,
>>> which could be very, very large. I doubt if that was your intent?
>>>
>>> Ken
>>>
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
>>> Sent: Wednesday, May 18, 2005 5:44 PM
>>> To: Windows File Systems Devs Interest List
>>> Subject: Re:[ntfsd] How to do page write?
>>>
>>> I accidently copied that code from an old version. Here is the correct
>>> code:
>>>
>>> InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
>>> OBJ_KERNEL_HANDLE, NULL, NULL );
>>>
>>> status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
>>> FILE_WRITE_DATA | FILE_APPEND_DATA, &attr, &ioStatus, (PLARGE_INTEGER)
>>> &initSize, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_CREATE,
>>> FILE_SEQUENTIAL_ONLY | FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0, 0 );
>>>
>>> status = FltWriteFile( gOutVolInstance, gOutputFileObject,
>>> (PLARGE_INTEGER)
>>> &gCurOutputFilePos, OUT_PAGE_SIZE, PagePtr,
>>> FLTFL_IO_OPERATION_NON_CACHED,
>>> &bytesWritten, CpsPageWriteCallback, PagePtr );
>>>
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>> 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@comcast.net
>> 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@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OSR_Community_User · May 18, 2005, 10:05pm

>

Do you think that my overall goal of acheiving higher priorities for my
writes will happen if I get paging writes to work? Am I doing all this for
nothing?

No, I don’t think that using paging IO provides any performance benefits.
There are no priorities associated with paging IO I know about.
Making it work will let better understand FS design but I doubt that there is
any practical reason to use it in your particular case. (Generating paging IO
can be useful under some circumstances, for example it allows to bypass file
range locking).

Alexei.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
>If you saw the corrected code you’ll see that I specified an initial file
>allocation size which happens to be the max size of my file. Doesn’t this
>mean it won’t have to extend the file, or is allocation size different from
>file size? How do I “explicitly extend” the file?

You should not mix allocation size (space allocated on the disk) and logical
file size (number of bytes you can read from the file). There is
IRP_MJ_SET_INFORMATION/FileEndOfFileInformation which allows to explicitly
set EOF. Normal (not paging IO) writes extends EOF when writing beyond EOF;
paging IO doesn’t extend EOF and since no data was written it returns 0 in
the information field.

>> cache consistency: during paging write FS doesn’t flush the cache so
>> stale

>> data from cache may overwrite your data when cache is flushed.

>I don’t understand this. I am not using the cache at all for this file. I
>am using the flags FLTFL_IO_OPERATION_NON_CACHED |
>FLTFL_IO_OPERATION_PAGING

>and allocating my own aligned memory.

If you are the only one who uses the file - then no data will be in the
cache. If somebody else (antivirus or indexing service for example) opens
the
file concurrently some data may end up in the cache.

>> depending on TopLevelIrp it may skip writing data beyond valid data
>> length
>
>This boils down to the same issue as your first point, right? If I make
>sure the length is correct when I start this shouldn’t be an issue.

Basically file systems maintain 3 different lengths for a file - Allocation
length, End of file and valid data length. They do have different values and
are changed at differnt time.

Alexei.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
Paging IO never extends EOF. You just created the file so its size is 0.
At least you need to explicitly extend file before writing out data using
Paging IO.

There are other potential problems using paging IO:
- cache consistency: during paging write FS doesn’t flush the cache so stale
data from cache may overwrite your data when cache is flushed.
- depending on TopLevelIrp it may skip writing data beyond valid data length

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Wednesday, May 18, 2005 11:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to do page write?

I have a mini-filter that watches writes and creates a journal. I am
writing my journal data to a file in a system thread that gets data from a
queue. The pre-write callbacks put data into the queue. The data I am
writing is getting delayed in the actual FltWriteFile call, even though it
is an non-cached async call. When this happens (during stress test) my
output queue backs up and fills up non-paged memory.

I was thinking that maybe if I used paged writes by turning on
FLTFL_IO_OPERATION_PAGING it might give my writes higher priority so they
don’t get behind. When I tried this the writes returned a
Data->IoStatus.Status of zero, but Data->IoStatus.Information was also zero,
correctly indicating it had written nothing. My output file was empty.

Are there any special rules about using FLTFL_IO_OPERATION_PAGING? I will
try doing sync writes instead of async and different output page sizes
instead of the 16K page size I am trying now.

Here are the pertinent parts of my code:

InitializeObjectAttributes( &attr, &fileName, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL );

status = FltCreateFile( gFilter, gOutVolInstance, &gOutputFileHandle,
FILE_APPEND_DATA | SYNCHRONIZE, &attr, &ioStatus, 0, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0, 0 );

FltWriteFile( gOutVolInstance, gOutputFileObject, NULL, OUT_PAGE_SIZE,
PagePtr, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_PAGING,
&bytesWritten, CpsPageWriteCallback, PagePtr );

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

You are currently subscribed to ntfsd as: xxxxx@vmware.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@vmware.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@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · May 19, 2005, 2:17am

> Just setting the EOF to some arbitrary value won’t actually extend the

file
(ala VMS ) – it will result in a sparse file with a big EOF.

Off-topic: Ah, this is answer to the question:
Why this operation

CreateFile(“C:\Hello.dat”, …)
SetFilePointer(hFile, 8 GB from file begin)
SetEndOfFile(hFile);
CloseHandle(hFile)

will generate a 8 GB file in less than half second ?

L.