Excuse me about my lame question, but i’ve researched this issue since two days, i read fastfat sources related to it, but without success. I’m writting a file system driver and there is a problem with IRP_MJ_WRITE routine. When I’m writting a single byte from the beggining of a file for example, the following sequence of events is happening:
- My write dispatch routine is invoked - operation is cached and non-paging. (Offset 0, Length 1).
- Because of cached operation, after some prerequisits I invoke CcCopyWrite and return success.
- A cleanup is comming -> i want to flush the cache, CcFlushCache, which causes page fault.
- The result from the page fault, a new write operation is comming to my driver. Operation is paging, and non-buffered. (Offset 0, Length 4096). Operation is successful.
- The data in the file, i initially want to write is written correct, but the write caused by the page fault extends the file size to 4096.
I found a thread in this forum where Maxim S. Shatskih says “Paging writes cannot extend the EOF value, while the non-paging non-cached writes can”, but what can i do - this paging write (offset 0, length 4096) extends the file? Do I have to truncate the file manualy in the cleanup routine (yet CcFlushCache in it provokes paging write) or something else? I tried this on simple NTFS volume and I noticed that after the paging write (marked by IRP_MJ_WRITE*) in filemon, is comming IRP_MJ_SET_INFORMATION* with the correct size, but this IRP_MJ_SET_INFORMATION* does not come in my driver.
You are developing file system, right? The metadata which describes file size is under your control. Just do not change file size when paging IO goes beyond EOF. In response to write request you probably will issue write to the underlying volume. When you prepare this write request for the volume truncate it so it fits into the space allocated for the file data. It does not need to be truncated exactly on EOF, truncate it to the nearest end of sector or end of cluster. Data beyond EOF has no meaning and thus it can be discarded.
Extending file and then truncating it in cleanup is wrong thing to do. If you do this there will be some time when the file size is wrong and visible to applications. It would confuse some applications for sure.
Alexei.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, February 04, 2009 9:35 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Paging I/O trouble
Excuse me about my lame question, but i’ve researched this issue since two days, i read fastfat sources related to it, but without success. I’m writting a file system driver and there is a problem with IRP_MJ_WRITE routine. When I’m writting a single byte from the beggining of a file for example, the following sequence of events is happening:
- My write dispatch routine is invoked - operation is cached and non-paging. (Offset 0, Length 1).
- Because of cached operation, after some prerequisits I invoke CcCopyWrite and return success.
- A cleanup is comming -> i want to flush the cache, CcFlushCache, which causes page fault.
- The result from the page fault, a new write operation is comming to my driver. Operation is paging, and non-buffered. (Offset 0, Length 4096). Operation is successful.
- The data in the file, i initially want to write is written correct, but the write caused by the page fault extends the file size to 4096.
I found a thread in this forum where Maxim S. Shatskih says “Paging writes cannot extend the EOF value, while the non-paging non-cached writes can”, but what can i do - this paging write (offset 0, length 4096) extends the file? Do I have to truncate the file manualy in the cleanup routine (yet CcFlushCache in it provokes paging write) or something else? I tried this on simple NTFS volume and I noticed that after the paging write (marked by IRP_MJ_WRITE*) in filemon, is comming IRP_MJ_SET_INFORMATION* with the correct size, but this IRP_MJ_SET_INFORMATION* does not come in my driver.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>You are developing file system, right? The metadata which describes file size is under your control.
Just do not change file size when paging IO goes beyond EOF.
IIRC FASTFAT does exactly this - it truncates such paging write to nearest sector boundary beyound EOF and zeroes the remainder (from actual EOF to the sector boundary).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
In addition to the other observations, I would note that if you call
CcSetFileSizes you should see the exact correct EOF information as well.
Tony
OSR