file opened with or without write through flag

I have pasted two stack traces and their correponding irp and file object.
The file object for first is opened without write through flag while second
is opened with that flag. The difference i found is that in first
case(without write through), Ntfs!NtfsCommonWrite always call nt!CcCanIWrite
first for making sure the cache is not full. But in case of file object
opened with write through flag, CcCanIWrite is never gets called. i.e
Ntfs!NtfsCommonWrite directly calls CcCopyWrite. Could any from you one
validate this bahaviour.

nt!CcCanIWrite (FPO: [Non-Fpo])
Ntfs!NtfsCommonWrite+0x282 (FPO: [Non-Fpo])
Ntfs!NtfsFsdWrite+0x16a (FPO: [Non-Fpo])
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
fltmgr!FltpDispatch+0x6f (FPO: [Non-Fpo])
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
naiavf5x+0x1bbe
naiavf5x+0x72ce
naiavf5x+0x2520
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo])
nt!NtWriteFile+0x65a (FPO: [Non-Fpo])
nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ f6116b00)nt!ZwWriteFile+0x11
(FPO: [9,0,0])
MyDrv!InWriteFile

0: kd> !irp 8557a008
Irp is active with 10 stacks 9 is current (= 0x8557a198)
No Mdl: No System Buffer: Thread 85783bd0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[4, 0] 0 e0 85f47718 85698b90 f6148b50-f6116998 Success Error Cancel
\FileSystem\Ntfs naiavf5x
Args: 00007000 00000000 000d8000 00000000
[4, 0] 0 0 857ab348 85698b90 00000000-00000000
\FileSystem\NaiAvFilter1
Args: 00007000 00000000 000d8000 00000000

0: kd> dt nt!_FILE_OBJECT 85698b90
+0x000 Type : 5
+0x002 Size : 0x70
+0x004 DeviceObject : 0x8613d610 _DEVICE_OBJECT
+0x008 Vpb : 0x8613f548 _VPB
+0x00c FsContext : 0xe5d6b3e0
+0x010 FsContext2 : 0xe6124568
+0x014 SectionObjectPointer : 0x857293f4 _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0x1 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x140042
+0x030 FileName : _UNICODE_STRING “\dataLogY1\WriteData1”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

nt!CcCopyWrite+0x29b (FPO: [Non-Fpo])
Ntfs!NtfsCommonWrite+0x1cea (FPO: [Non-Fpo])
Ntfs!NtfsFsdWrite+0x16a (FPO: [Non-Fpo])
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
fltmgr!FltpDispatch+0x6f (FPO: [Non-Fpo])
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
naiavf5x+0x1bbe
naiavf5x+0x72ce
naiavf5x+0x2520
nt!IofCallDriver+0x45 (FPO: [Non-Fpo])
nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo])
nt!NtWriteFile+0x65a (FPO: [Non-Fpo])
nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ f646ba10)
nt!ZwWriteFile+0x11 (FPO: [9,0,0])
MyDrv!InWriteFile

kd> !irp 85504868
Irp is active with 10 stacks 9 is current (= 0x855049f8)
No Mdl: No System Buffer: Thread 85742810: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[4, 0] 4 e0 85d6e718 85f51ad8 f6495b50-f646b8a8 Success Error Cancel
\FileSystem\Ntfs naiavf5x
Args: 00001000 00000000 00102200 00000000
[4, 0] 4 0 8580df08 85f51ad8 00000000-00000000
\FileSystem\NaiAvFilter1
Args: 00001000 00000000 00102200 00000000
kd> dt nt!_FILE_OBJECT 85f51ad8
+0x000 Type : 5
+0x002 Size : 0x70
+0x004 DeviceObject : 0x86116288 _DEVICE_OBJECT
+0x008 Vpb : 0x86155288 _VPB
+0x00c FsContext : 0xe5a375d8
+0x010 FsContext2 : 0xe5bab098
+0x014 SectionObjectPointer : 0x85de8f5c _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : 0x85797518
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0x1 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x1c1052
+0x030 FileName : _UNICODE_STRING “\dataLogY1\WriteData”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x103200
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

FO_WRITE_THROUGH flag means that requested write operation is considered complete only when data is transferred to the file. Therefore, calling CcCanIWrite() just does not seem to make sense here - instead, calling CcCopyWrite() with Wait set to TRUE seems to be a better idea (if you do it this way, you can be sure that, by the time it returns, the operation has been completed)

Anton Bassov

“This argument(wait) is only accepted by the CcCopyWrite () routine. The
caller
can decide whether blocking for disk I/O is acceptable or not. For example,
in order to modify a byte range in memory, free pages are required. To free
up physical memory, some data may have to be transferred to disk. This
involves disk (or network) I/O, which is a blocking operation.”

these lines are from rajeev nagar book. file is opened with write through
flag

“some data may have to be transferred to disk”. who will do this write.
Modified page writer thread or lazy writer component.

On 6/19/07, xxxxx@hotmail.com wrote:
>
> FO_WRITE_THROUGH flag means that requested write operation is considered
> complete only when data is transferred to the file. Therefore, calling
> CcCanIWrite() just does not seem to make sense here - instead, calling
> CcCopyWrite() with Wait set to TRUE seems to be a better idea (if you do it
> this way, you can be sure that, by the time it returns, the operation has
> been completed)
>
> Anton Bassov
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Regards
Rohit Gauba

“A positive thought is the seed of a positive result”

> who will do this write. Modified page writer thread or lazy writer component.

Well, lazily flushing seems to be just incompatible with FO_WRITE_THROUGH flag, don’t you think?

Anton Bassov

Is it possible that read operation can cause flush in case file is opened
with write through flag. I know this flag is used for write operations. But
due to this flag all data belonging to this file stream is not modified. if
data requested does not exist in cache, then through page fault mechanism we
can get it from disk but for that we need memory where we cache the newly
arrived data. At that time we can discard some of the pages from this file
stream cache and we donot need to flush cache. Is this statement is true or
not.

On 6/20/07, xxxxx@hotmail.com wrote:
>
>
>
> > who will do this write. Modified page writer thread or lazy writer
> component.
>
> Well, lazily flushing seems to be just incompatible with FO_WRITE_THROUGH
> flag, don’t you think?
>
> Anton Bassov
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Regards
Rohit Gauba

“A positive thought is the seed of a positive result”

Actually, I think that if the system needs memory that your file occupies, it can just free it without flushing - once FO_WRITE_THROUGH flag forces any write operation to be immediately flushed to disk anyway, there is no need for the flushing it when freeing pages…

Anton Bassov