Hello,
I would like to know how to detect from IRP_MJ_WRITE whether it is a lazy
write (or write behind) by Cache Manager? My driver hooks on IRP_MJ_WRITE
and wants to skip lazy write by passing the IRP directly down to lower file
system.
Can I assume that if a specific filename has been opened and closed
subsequently (by monitoring the open and close IRPs), and I still receive an
IRP_MJ_WRITE request for the filename, it is a lazy write operation?
Please correct me if I am wrong.
Thank you!
Sin-Lam
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> I would like to know how to detect from IRP_MJ_WRITE whether it is a
lazy
write (or write behind) by Cache Manager? My driver hooks on IRP_MJ_WRITE
and wants to skip lazy write by passing the IRP directly down to lower
file
system.
Set the TopLevelIrp field of the thread to some value of yours in
AcquireFileForLazyWrite callback. Then check the TopLevelIrp to be this
value in the write path.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi Max,
Thanks for the information. My driver is a file system filter driver like
filemon, it monitors IRP_MJ_WRITE from usermode applications or ZwWriteFile
from another driver. If I simply check the Irp->flags for IRP_PAGING_IO, can
I assume this is lazy write operation?
Regards,
Sin Lam
> I would like to know how to detect from IRP_MJ_WRITE whether it is a
lazy
> write (or write behind) by Cache Manager? My driver hooks on
IRP_MJ_WRITE
> and wants to skip lazy write by passing the IRP directly down to lower
file
> system.
Set the TopLevelIrp field of the thread to some value of yours in
AcquireFileForLazyWrite callback. Then check the TopLevelIrp to be this
value in the write path.
Max
You are currently subscribed to ntfsd as: xxxxx@krdl.org.sg
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
Set the TopLevelIrp field of the thread to some value of yours in
AcquireFileForLazyWrite callback. Then check the TopLevelIrp to be this
value in the write path.
The AcquireFileForLazyWrite callback is set during CcInitializeCacheMap(). I
don’t see how a filter driver can set it’s own callback routine. If it could
than the locks and the TopLevelIrp values that the filter driver sets won’t
be the ones expected by the file system. Am I missing something ?
Sara
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> from another driver. If I simply check the Irp->flags for IRP_PAGING_IO,
can
I assume this is lazy write operation?
No. It can be the CcFlushCache called by the FSD, FlushViewOfFile called by
the user-mode code or the MPW thread.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > Set the TopLevelIrp field of the thread to some value of yours in
> AcquireFileForLazyWrite callback. Then check the TopLevelIrp to be this
> value in the write path.
>
The AcquireFileForLazyWrite callback is set during CcInitializeCacheMap().
I
don’t see how a filter driver can set it’s own callback routine.
The filter can examine the TopLevelIrp set by the filesystem.
Otherwise - there is no way of distinguishing the lazy writer (which IIRC
does CcFlushCache internally) from the explicit CcFlushCache called by the
FSD code.
The only difference is that lazy writer’s CcFlushCache is framed by
Acquire/ReleaseFileForLazyWrite callbacks, while the FSD’s CcFlushCache is
framed by Acquire/ReleaseFileForCcFlush callbacks.
Note that MM also sometimes uses AcquireFileForCcFlush - IIRC the user-mode
FlushViewOfFile results in it.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Max,
Looking at the FatAcquireFcbForLazyWrite/FatAcquireForCcFlush routines for
fastfat (resrcsup.c), it seems that both set TopLevelIrp to
FSRTL_CACHE_TOP_LEVEL_IRP. AcquireFcbForLazyWrite() sets:
((PFCB)Fcb)->Specific.Fcb.LazyWriteThread = PsGetCurrentThread()
and that’s how the write() code identifies a lazy write operation.
So, again, I don’t see how a filter driver in NT/W2K can recognize a write
originated by the lazy writer.
Sara
The filter can examine the TopLevelIrp set by the filesystem.
Otherwise - there is no way of distinguishing the lazy writer (which IIRC
does CcFlushCache internally) from the explicit CcFlushCache called by the
FSD code.
The only difference is that lazy writer’s CcFlushCache is framed by
Acquire/ReleaseFileForLazyWrite callbacks, while the FSD’s CcFlushCache is
framed by Acquire/ReleaseFileForCcFlush callbacks.
Note that MM also sometimes uses AcquireFileForCcFlush - IIRC the
user-mode
FlushViewOfFile results in it.
Max
You are currently subscribed to ntfsd as: xxxxx@veritas.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com