Hello Experts.
I a, trying to write a filesystem driver to revert changes made to file residing on the volume. I have written basic mini-filter drivers before and i am able to access information about file been processed just like the Mini-spy provided by WDK. I read few articles, blogs and also some questions here on OSR all recommending to redirect Writes to a overlay location ensuring changes are not made to the original location just like File-Based Write Filter. Now if that’s the way to proceed, i would like some hints about how do i create the mapping table of logical blocks to offsets of writes to that overlay location so that i can guaranty applications and users still access consistent data blocks.
If you are maintaining a flat file to contain all the redirected writes
then simply track the source and target offset/length pairs. If you are
also maintaining multiple file writes within a single redirected
location then you would also need to maintain a file identifier. For
performance reason, try to keep as much of this in memory, at least the
redirection information such as the source and target offset/length
pairs but if you also need persistence then have it written out to some
sort of database or custom file which maintains this information.
Note that with this approach you are moving into a layered file system
of sorts where you are maintaining an underlying file object to redirect
IO requests to. It definitely begins to get much more complex over the
mini-spy filter driver you ahve started with in your project.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295
------ Original Message ------
From: xxxxx@yahoo.fr
To: “Windows File Systems Devs Interest List”
Sent: 7/23/2015 1:27:32 AM
Subject: [ntfsd] How do i redirect writes and create a mapping table of
logical blocks to offsets
>Hello Experts.
>I a, trying to write a filesystem driver to revert changes made to file
>residing on the volume. I have written basic mini-filter drivers before
>and i am able to access information about file been processed just
>like the Mini-spy provided by WDK. I read few articles, blogs and also
>some questions here on OSR all recommending to redirect Writes to a
>overlay location ensuring changes are not made to the original location
>just like File-Based Write Filter. Now if that’s the way to proceed, i
>would like some hints about how do i create the mapping table of
>logical blocks to offsets of writes to that overlay location so that i
>can guaranty applications and users still access consistent data
>blocks.
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars 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
Things are more clear now, Thank you very much.
You should consider filtering the block device (volume device) underneath
the file system and not the file system (see the diskperf example in the
WDK). It will make your job much easier, and you will not care about the
file system on top. When you are done, just throw away the changes. If you
expect a large number of changes or want to keep the changes across boots,
write them to a file somewhere.
On writes, capture data, stash away, and complete request.
On reads, first read the data from the real disk, patch your reads with
data you may have stashed away, and complete request.
ᐧ
On Thu, Jul 23, 2015 at 10:37 PM, wrote:
> Things are more clear now, Thank you very much.
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
One more thing:
For mapping, use RtlGenericTableAvl routines to keep track of of your
stashed blocks.
ᐧ
On Fri, Jul 24, 2015 at 12:31 AM, Jamey Kirby wrote:
> You should consider filtering the block device (volume device) underneath
> the file system and not the file system (see the diskperf example in the
> WDK). It will make your job much easier, and you will not care about the
> file system on top. When you are done, just throw away the changes. If you
> expect a large number of changes or want to keep the changes across boots,
> write them to a file somewhere.
>
> On writes, capture data, stash away, and complete request.
> On reads, first read the data from the real disk, patch your reads with
> data you may have stashed away, and complete request.
>
>
> ᐧ
>
> On Thu, Jul 23, 2015 at 10:37 PM, wrote:
>
>> Things are more clear now, Thank you very much.
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system seminars 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
>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
Thank you very much for additional information, it is very much appreciated. I’ll then explore the diskperf WDK sample as i want a much easier job.
Cheers.
Just note that filtering at the volume layer results in a different product
than filtering at the file system layer.
At the file system layer, you’re redirecting I/Os targeting a particular
stream or file. This would (in theory) allow you to restore a particular
file to its original state without perturbing the other files on the volume.
If you track changes at the volume level your restore affects all files on
the volume.
Both have their challenges. However, where you need to filter really depends
on what you want your end product to do.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Thank you very much for additional information, it is very much appreciated.
I’ll then explore the diskperf WDK sample as i want a much easier job.
Cheers.
I now clearly see the difference, Thank you all. However as suppose i decide to throw away the changes in a file or collection of files referenced by ID somewhere on the disk and associate respective mapping tables for the block data offsets, is that or those files going to be visible by some users? I know its possible to hide files by setting the hidden attribute flag but the single fact that they can be visible on user mode kind of worry me. Am i right or missing something? I know for performance it is a good practice to have many files where i stash away the changes instead of throwing them on a single location.
Sure, why wouldn’t they be? You can secure the files with an appropriate
ACL. Also, you’ll presumably keep these files open with no sharing
specified. Both of these will keep the casual user away from mucking with
your data.
Note that this is how VSS works, it creates files in the System Volume
Information folder that contain the COW data.
I’m not sure how having multiple files would necessarily give you better
performance…
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
I now clearly see the difference, Thank you all. However as suppose i decide
to throw away the changes in a file or collection of files referenced by ID
somewhere on the disk and associate respective mapping tables for the block
data offsets, is that or those files going to be visible by some users? I
know its possible to hide files by setting the hidden attribute flag but the
single fact that they can be visible on user mode kind of worry me. Am i
right or missing something? I know for performance it is a good practice to
have many files where i stash away the changes instead of throwing them on a
single location.
First of all, I want to thank all of you for your time trying to provide answers to my misunderstandings, I am still a newbie to driver development.
I have examined the diskperf sample and being able to understand most of it. My assignment consists of storing the modified blocks on the same volume and for that i was considering throwing them on a flat file while maintaining a mapping table of offset, but i think (correct me if i’m wrong) saving them on a file residing on the same volume won’t work since the protection applies to the whole partition. I am able to get the write’s data, able to store the write offset in an AVL structure though. So here are my questions.
- Since i expect a lot of change, how do i get the next free space on disk to stash the writes away? I read here that I should create a bitmap of the volume and consequently be able to retrieve free sectors numbers and write on them, if that’s the case, can you clarify what i need to do that?
Also is a storage filter driver the kind i need to add exclusions so that certain IRPs are filtered depending on some conditions: like the process that is responsible of the thread writing data to disk?
Thank you.