Non-cached write does not work on 2003

Yes, Alexei is correct. NTFS will allow paging IO from the mapped page
writer extend valid data length. Sorry about that.

As to whether or not this will work, I can’t say for sure since I’ve
never tried it. Testing will be your best verifier.

Thanks,
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 Ladislav Zezula
Sent: Friday, April 23, 2004 1:27 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Non-cached write does not work on 2003

If you clear PAGING_IO that changes your filter by far. Depending on
what
calls
you let through and which you do yourself you might need to call it. I
think you
will, but only you can tell:-)

For now, I have set the Top Level Irp to simulate modified page writer.
This seems that it works, but I have to play with it at least some days
to be sure.

L.


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

According to Rajeev Nagar:

  • EOF cannot be extended by paging IO.
  • VDL is extended only by the top-level writer (MPW can be such).

IIRC the correct way of writing to cache is - extend EOF, then CcCopyWrite,
then extend VDL. Rollback EOF extension if CcCopyWrite fails.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Alexei Jelvis”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, April 23, 2004 6:18 AM
Subject: Re:[ntfsd] Non-cached write does not work on 2003

> Molly,
>
> You are saying that PAGING_IO doesn’t extend valid data length.
> Correct me if I am wrong, but I believe that PAGING_IO originated from the
> modified page writer does extend valid data length and doesn’t change EOF.
> So by changing TopLevelIrp you can convince NTFS that IRP_MJ_WRITE is
> originated by modified page writer and thus need to be written to the disk.
> I wonder what problems may cause changing TopLevelIrp just before calling
> NTFS and restoring it back immediately after?
> It is probably safer then removing paging IO flag IRP.
>
> Alexei.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> First, I’ll answer the easy part of the question –
>
> The FILE_VALID_DATA_LENGTH_INFORMATION docs are incorrect (sorry we
> missed that in review). ValidDataLength must be less than or equal to
> file size. It cannot be greater than file size. I’ll talk to Diane
> about getting the docs corrected.
>
> Now the more complicated part –
>
> From your previous email, you showed that the IRP you send down to the
> file system when forwarding the lazy writer’s write has the PAGING_IO
> flag set. NTFS does not expect PAGING_IO to extend the valid data
> length of the file. In this scenario, NTFS expects to have seen the
> cached write and NTFS would have extended the valid data length at that
> time. Therefore, when the lazy writer’s write comes along, it looks
> like PAGING_IO and NTFS ignores such writes which extend valid data
> length (returns STATUS_SUCCESS, length = 0 as you are seeing).
>
> To set the valid data length of a file through IRP_MJ_SET_INFORMATION,
> the user needs to have SE_MANAGE_VOLUME_PRIVILEGE and this is enforced
> by NTFS. The SDK docs for SetFileValidData describes the intended use
> for this operation and what you are trying to do is not listed there ;).
>
> In any case, extending the valid data length will cause NTFS to 0 this
> range of the file. That’s unnecessary since you’ve go the real data
> which you want stored in that range of the file.
>
> I’d suggest clearing the PAGING_IO flag when you send the non-cached
> write IRP down to NTFS. Then this write will just look like a regular
> non-cached, write which extends the file and NTFS will do the right
> thing to update it’s internal file sizes.
>
> One caveat here: I’m assuming that since your filter is taking over the
> caching on the data stream, your filter is also taking responsibility
> for the locking on the file. NTFS won’t be getting the internal Cc
> callbacks (the ones registered with Cc when CcInitializeCacheMap is
> called), so it would be up to your filter do the appropriate
> synchronization.
>
> 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 Ladislav Zezula
> Sent: Wednesday, April 21, 2004 10:42 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Non-cached write does not work on 2003
>
> Hi,
>
> thank you very much for the response.
>
> > Can you tell me what your filter/file system thinks is the FileSize
> and
> > ValidDataLength for the stream and what Ntfs thinks is the FileSize
> and
> > ValidDataLength for this stream?
>
> Yes, of course :-))
> First, I have to briefly explain our logic. Let’s imagine simple
> example of CreateFile(new_file)-WriteFile(0x10000 bytes)-CloseHandle.
> When the write comes (cached first), our filter increases
> the file size to number of bytes to be written (thus, 0x10000
> bytes) using IRP_MJ_SET_INFORMATION(FileEndOfFileInfo)
> using our duplicated file object, so the lower FS knows that the file
> size changed.
> Then we call CcCopyWrite on the file object coming from I/O manager.
> After a while (while means when CcWorkerThread - CcWriteBehind
> awakes), the non-cached write comes to our filter (0x10000 bytes).
> In this moment, the AllocationSize and FileSize in the FS FCB
> is set to 0x10000, but the ValidDataLength is set to zero.
> (Our filter thinks it is 0x10000 0x10000 0x10000)
>
> Then our filter calls the underlying FS to write the data
> (non-cached). NtfsFsdWrite returns STATUS_SUCCESS
> and the IoStatus.Information contains zero.
>
> Well the problem is not in NTFS, but between my chair
> and keyboard (as usually :-))). I probably have to set
> the ValidDataLength too. But one thing worries me -
> IFS documentation says that when I call IRP_MJ_SET_INFORMATION
> (FileValidDataLengthInfo), the ValidDataLength must be
> greater than the previous ValidDataLength (which is no problem)
> BUT less than the current file size (which means it cannot be equal).
>
> I’m convinced that I cannot simply change the ValidDataLength
> in the FCB header of the FS FileObject (I didn’t even tried, because I
> do not want to see the buch of bugchecks because of such dirty
> hack).
>
> L.
>
>
> —
> 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: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com