Hi all,
We are implementing a change log journal for blocks of a volume. The journal
file NEEDS to reside on the same volume and must track boot time changes.
For the same we have a volume filter driver that tracks all the write IRPS.
Now i want to write journal info to the file.
Is there any way i can detect IRP’s / Write request made by my volume filter
so that volume filter does not monitor them.
Thanks & Regards
Faraz Ahmed.
If you are using an actual file to store your change log information, then
there is no fully comprehensive way to do it. You could create the file
non-cached and thus your requests would be issued in the context of your
thread down the stack into your driver, thus you could recognize it. But in
the case of NTFS compression, it will create a cache map anyway, even if you
specify non-cached for the file. Thus when the cache is flushed, it will
sometimes be in some other context and you won’t recognize it. Also,
consider situations where someone in the filesystem stack swaps thread
contexts while processing the write, for whatever reason, then you are out
of luck again.
A different approach would be to allocate a file of some initial size, say
64KB. Locate the extents of this file on disk and write to those sectors
directly from your volume filter. When you have exhausted the space, extend
the file, get the extents and keep dumping data to it. Of course you will
need to be sure that when you extend the file you actually write out data to
the extended size, like a bunch of zero’s. This way the lengths are
correctly maintained by the FSD and it is not handled as a sparse file, you
would only be changing the contents of the data not the lengths from your
volume filter driver. A little tricky but it can be worked out, I have done
this.
Another option would be to determine the extents of the file when it is
being written to, tag those sectors as ‘pass through’ and don’t reprocess
writes to those sectors. The problem here is the determination of the extent
information of the log file before it has been written to, going back to the
option described above.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
Sent: Monday, September 19, 2005 2:43 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Avoiding Recursion.
Hi all,
We are implementing a change log journal for blocks of a volume. The
journal file NEEDS to reside on the same volume and must track boot time
changes. For the same we have a volume filter driver that tracks all the
write IRPS. Now i want to write journal info to the file.
Is there any way i can detect IRP’s / Write request made by my
volume filter so that volume filter does not monitor them.
Thanks & Regards
Faraz Ahmed.
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com
> A different approach would be to allocate a file of some initial size,
say 64KB. Locate the extents of this file on disk and write to those
sectors directly from your volume filter.
I have seen a commercial disk encryptor that made
it exactly this way.
L.
Thanks Scott for the informational reply;
The second approach looks good, any pointers other than
“Mark Roddy’s Adventures in LuserLand” to implement the same?.
Also if we choose the second approach is there any way to
correctly maintian the log files meta-data like access times etc.
Thanks and regards
Faraz.
On 9/19/05, Peter Scott wrote:
>
>
> If you are using an actual file to store your change log information, then
> there is no fully comprehensive way to do it. You could create the file
> non-cached and thus your requests would be issued in the context of your
> thread down the stack into your driver, thus you could recognize it. But in
> the case of NTFS compression, it will create a cache map anyway, even if
> you
> specify non-cached for the file. Thus when the cache is flushed, it will
> sometimes be in some other context and you won’t recognize it. Also,
> consider situations where someone in the filesystem stack swaps thread
> contexts while processing the write, for whatever reason, then you are out
> of luck again.
>
>
>
> A different approach would be to allocate a file of some initial size, say
> 64KB. Locate the extents of this file on disk and write to those sectors
> directly from your volume filter. When you have exhausted the space, extend
> the file, get the extents and keep dumping data to it. Of course you will
> need to be sure that when you extend the file you actually write out data
> to
> the extended size, like a bunch of zero’s. This way the lengths are
> correctly maintained by the FSD and it is not handled as a sparse file, you
> would only be changing the contents of the data not the lengths from your
> volume filter driver. A little tricky but it can be worked out, I have done
> this.
>
>
>
> Another option would be to determine the extents of the file when it is
> being written to, tag those sectors as ‘pass through’ and don’t reprocess
> writes to those sectors. The problem here is the determination of the
> extent
> information of the log file before it has been written to, going back to
> the
> option described above.
>
>
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> _____
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
> Sent: Monday, September 19, 2005 2:43 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Avoiding Recursion.
>
>
>
> Hi all,
> We are implementing a change log journal for blocks of a volume. The
> journal file NEEDS to reside on the same volume and must track boot time
> changes. For the same we have a volume filter driver that tracks all the
> write IRPS. Now i want to write journal info to the file.
> Is there any way i can detect IRP’s / Write request made by my
> volume filter so that volume filter does not monitor them.
>
> Thanks & Regards
> Faraz Ahmed.
>
>
>
>
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
> ntfsd as: unknown lmsubst tag argument: ‘’ 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@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You are by-passing the FSD so, no, using this method only will not maintain
the files meta-data, Though just as you will have to extend the file from
some context which does go through the FSD, this will also update the times
on the file.
The approach is fairly straight forward. Not sure where there would be any
good reference information on it, other than code that people have written
on this list. Which I doubt they would be willing to part with gratis.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
Sent: Tuesday, September 20, 2005 3:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Avoiding Recursion.
Thanks Scott for the informational reply;
The second approach looks good, any pointers other than
“Mark Roddy’s Adventures in LuserLand” to implement the same?.
Also if we choose the second approach is there any way to
correctly maintian the log files meta-data like access times etc.
Thanks and regards
Faraz.
On 9/19/05, Peter Scott wrote:
>
>
> If you are using an actual file to store your change log information, then
> there is no fully comprehensive way to do it. You could create the file
> non-cached and thus your requests would be issued in the context of your
> thread down the stack into your driver, thus you could recognize it. But
in
> the case of NTFS compression, it will create a cache map anyway, even if
> you
> specify non-cached for the file. Thus when the cache is flushed, it will
> sometimes be in some other context and you won’t recognize it. Also,
> consider situations where someone in the filesystem stack swaps thread
> contexts while processing the write, for whatever reason, then you are out
> of luck again.
>
>
>
> A different approach would be to allocate a file of some initial size, say
> 64KB. Locate the extents of this file on disk and write to those sectors
> directly from your volume filter. When you have exhausted the space,
extend
> the file, get the extents and keep dumping data to it. Of course you will
> need to be sure that when you extend the file you actually write out data
> to
> the extended size, like a bunch of zero’s. This way the lengths are
> correctly maintained by the FSD and it is not handled as a sparse file,
you
> would only be changing the contents of the data not the lengths from your
> volume filter driver. A little tricky but it can be worked out, I have
done
> this.
>
>
>
> Another option would be to determine the extents of the file when it is
> being written to, tag those sectors as ‘pass through’ and don’t reprocess
> writes to those sectors. The problem here is the determination of the
> extent
> information of the log file before it has been written to, going back to
> the
> option described above.
>
>
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> _____
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
> Sent: Monday, September 19, 2005 2:43 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Avoiding Recursion.
>
>
>
> Hi all,
> We are implementing a change log journal for blocks of a volume.
The
> journal file NEEDS to reside on the same volume and must track boot time
> changes. For the same we have a volume filter driver that tracks all the
> write IRPS. Now i want to write journal info to the file.
> Is there any way i can detect IRP’s / Write request made by my
> volume filter so that volume filter does not monitor them.
>
> Thanks & Regards
> Faraz Ahmed.
>
>
>
>
>
>
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to
> ntfsd as: unknown lmsubst tag argument: ‘’ 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@gmail.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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com