COW file isolation model

NTFSD
1

Hi all,

Regarding COW on files, the easy aproach is to copy the whole file to a new location on MJ_CREATE. But my question is this other aproach possible:

  1. On pre create we let the operation be satisfied by the FS. On post create, if operation success, we would create a new sparse file. Thus we would have 2 FOs.
  2. On read file, we let the operation be satisfied with the original FO.
  3. On write file, we would change the target FO with the FO of the sparse file. We should mantain a map of the modified regions of the file.
  4. On read file, if the read is from a modified region, we change the target FO with the sparse FO

I suppose that this aproach has some incoherencies. For example, a process writes 10 bytes to offset 0. We change target FO, and the write is done on the sparse file, so the file offset gets updated in the sparse FO. I guess there are some more issues like this.

Do you know guys any way of solving these problems or it’s better to forget about such aproach?

Thx!

2

There are locking issues you will have to deal with. For example, one of
the pre-acquire fast IO callbacks are invoked by the lazy writer, this
would be on the FO that is handled by the underlying FS. You then
receive the paging IO and redirect it to the sparse file which does not
have the correct locks taken. As well, if the extents have not been
allocated within the sparse file when the paging write is sent, there
will be other issues.

In general, you should take ownership of the top level FO and redirect
to either the ‘real’ file or the redirected file, accordingly. You
handle all lock processing, etc. Much more complicated but you don’t run
into the edge cases with the above design.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.es
To: “Windows File Systems Devs Interest List”
Sent: 3/21/2017 11:06:16 AM
Subject: [ntfsd] COW file isolation model

>Hi all,
>
>Regarding COW on files, the easy aproach is to copy the whole file to a
>new location on MJ_CREATE. But my question is this other aproach
>possible:
>
>1) On pre create we let the operation be satisfied by the FS. On post
>create, if operation success, we would create a new sparse file. Thus
>we would have 2 FOs.
>2) On read file, we let the operation be satisfied with the original
>FO.
>3) On write file, we would change the target FO with the FO of the
>sparse file. We should mantain a map of the modified regions of the
>file.
>4) On read file, if the read is from a modified region, we change the
>target FO with the sparse FO
>
>I suppose that this aproach has some incoherencies. For example, a
>process writes 10 bytes to offset 0. We change target FO, and the write
>is done on the sparse file, so the file offset gets updated in the
>sparse FO. I guess there are some more issues like this.
>
>Do you know guys any way of solving these problems or it’s better to
>forget about such aproach?
>
>Thx!
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

3

But even if I take ownership of the top FO and redirect by myself to the corresponding FO depending the type of operation, each FO would end up having It’s offset (and probably other fields) updated separatelly and that could also cause inconsistencies, isn’t that right?