Staying an FS legacy filter driver

[sskras]

In one of my comment in #375 (reply in thread) I was surprised to see <Legacy> instead of Num Instances, Altitude, and Frame fields for OpenZFS driver.

Then I found FLTMC - Windows CMD - SS64.com page which says:

Altitude

Minifilters are assigned a specific altitude by Microsoft. This will sit within a range that is specific to the function of the minifilter.
e.g. Anti-Virus minifilters are assigned an altitude between 320,000 and 329,999.
and encryption minifilters are assigned an altitude between 140,000 and 149,999.

For file Writes, Altitudes are processed in descending order.
For file Reads, Altitudes are processed in ascending order.

So when writing anti-virus is handled before encryption, but when reading decryption is handled before anti-virus.

Legacy filter drivers do not use the minifilter model, this means they don’t slot into place based on their altitude. For interoperability with legacy filter drivers, the filter manager can attach filter device objects to a file system I/O stack in more than one location [example]. However you should still consider replacing legacy filters with minifilters.

[sskras]

@lundman, does this mean that the current implementation uses an older driver model called "FS legacy filter driver"?
https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/about-file-system-legacy-filter-drivers

If I got this right, do you have any ideas or even plans about porting the driver to the current filter manager model? Quoting:
https://learn.microsoft.com/en-gb/windows-hardware/drivers/ifs/guidelines-for-porting-legacy-filter-drivers

Guidelines for Porting Legacy Filter Drivers

Article · 15/12/2021 · 2 contributors

Developers are encouraged to port legacy filter drivers to the filter manager model to obtain better functionality for their filter drivers and improve system reliability. Experienced developers should find it relatively easy to port a legacy filter driver to a minifilter driver. Filter driver developers at Microsoft recommend the following approach:

• Start with a reliable regression test suite to verify behavior between the legacy filter driver and the ported minifilter driver.

• Create a minifilter driver shell and systematically move functionality from the legacy filter driver to the minifilter driver. For example, get attachment working and then port one operation at a time, testing after each operation.

• Change user-mode/kernel-mode communication last, so you can use existing tools to test the minifilter driver.

• Compile with PREfast and test with the Filter Verifier I/O verification option in Driver Verifier enabled.

[sskras]

I installed latest version of WinBTRFS. Then I tried to compare OpenZFS driver to it and to NTFS driver:

$ driverquery | grep -i -e Date -e === -e zfs -e btrfs -e ntfs
Module Name  Display Name           Driver Type   Link Date
============ ====================== ============= ======================
btrfs        btrfs                  Kernel        16/03/2024 02:08:20
Ntfs         Ntfs                   File System
OpenZFS      OpenZFS                Kernel        01/09/2023 07:49:05

Strangely enough both OpenZFS and WinBTRFS are listed as "Kernel drivers", while NTFS is listed as "File System" drivers. Why is the difference?

Then I rechecked list of loaded FS filter drivers:

$ sudo fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1       409800         1
storqosflt                              0       244000         1
wcifs                                   0       189900         1
CldFlt                                  1       180451         1
OpenZFS                                                     <Legacy>
FileCrypt                               0       141100         0
luafv                                   1       135000         0
npsvctrig                               1        46000         0
Wof                                     3        40700         0
FileInfo                                6        40500         0

... and the WinBTRFS driver, btrfs.sys still isn't present here.

Although it seems to be working:

... and WMI recognize the FS type, the B: driver letter:

saukrs@DESKTOP-O7JE7JE MSYS ~
$ wmic volume get caption,FileSystem
Caption                                            FileSystem
D:\                                                NTFS
C:\                                                NTFS
\\?\Volume{878041e1-48c2-484b-bcc1-507b0ff19c4c}\  NTFS
\\?\Volume{5feefb5c-468a-4da8-9fcc-0dfba19dcab8}\  FAT32
\\?\Volume{e24f4a77-14e4-3367-afa7-b538e0dd6bca}\  FAT32
B:\                                                Btrfs
E:\
\\?\Volume{00000000-0000-0000-0c00-0f00fa7f0000}\

---

This raises another question – what does OpenZFS for Windows use filter driver for (if any)?

[lundman]

Ah very interesting - I went with whatever worked at the time, it was a steep learning curve. But if we can figure out how to modernise it, we should do so.

[lundman]

Having a btrfs tab in the dialog is sexy, we should have that!

[sskras]

@lundman writes:

I went with whatever worked at the time, it was a steep learning curve. But if we can figure out how to modernise it, we should do so.

Nice to hear. And no wonder – I assume IFS drivers to be among the most complex software parts of the OS.

But let me summarize my two questions:

• what does OpenZFS for Windows use filter driver for (if any)?

  IOW: what if the project drops the "filter driver" part from implementation at all ?

• both OpenZFS and WinBTRFS are listed as "Kernel drivers", while NTFS is listed as "File System" drivers. Why is the difference?

  IOW: is this a matter of some identification constant configured somewhere in the project settings, or rather some architectural decision and a different code structure?

[lundman]

I am not sure we should be a filter, since we are presumably at the bottom (top?) of the stack being a filesystem. I could be wrong, but are any other filesystems like fastfat, ntfs, btrfs etc listed with an "altitude" etc?

We can in fact change to be "file system" instead of kernel drivers, there is an ENUM near the start of the registration of the driver code in hmm the .inf?. I suspect btrfs went with kernel over filesystem as both btrfs and zfs are more than a filesystem, since we do storage pools etc.

[sskras]

(as my reply became large, I'm moving it out as a separate comment)

@lundman writes:

I am not sure we should be a filter, since we are presumably at the bottom (top?) of the stack being a filesystem.

Thanks. OK, so I take it to be a rather unintentional outcome.

I could be wrong, but are any other filesystems like fastfat, ntfs, btrfs etc listed with an "altitude" etc?

As you see in #376 (comment) above, none.
9 minifilters out of 10 come from Microsoft, and none is serving the basis (fundamental) file system.

Tried googling: https://nostarch.com/download/EvadingEDR_chapter6.pdf#page=4

[...]

[...]

... and it seems that altitude applies only to minifilter drivers. The fully featured FS drivers are the final point in file I/O handling, thus no altitude here, IIUC.

On my first sight ZFS formally could be falling into these categories:

Altitude range	Load-order group name	Minifilter role
300000–309998	FSFilter Replication	Replication Drivers that copy data to a remote system
240000–249999	FSFilter Quota Management	Drivers that provide enhanced filesystem quotas that limit the space allowed for a volume or folder
180000–189999	FSFilter HSM	Hierarchical storage management drivers
160000–169999	FSFilter Compression	File-data compression drivers
140000–149999	FSFilter Encryption	File-data encryption and decryption drivers
120000–129999	FSFilter Physical Quota Management	Drivers that manage quotes by using physical block counts
100000–109999	FSFilter Open File	Drivers that provide snapshots of already-opened files

But I believe these are FS-agnostic roles, not tied to a specific FS. Thus probably irrelevant to OpenZFS.

We can in fact change to be "file system" instead of kernel drivers, there is an ENUM near the start of the registration of the driver code in hmm the .inf?. I suspect btrfs went with kernel over filesystem as both btrfs and zfs are more than a filesystem, since we do storage pools etc.

Oh, fair enough! I had forgot about the RAID layer and stuff. Thanks again.

[lundman]

Very interesting, thanks for sharing. It's hard to feel confident with Microsoft knowledge, there are a lot of information, and those in the know seem reluctant to share.

[besterino]

The MS knowledge bearers probably don’t look in here. Or they are still scared about the ZFS-license-thingy. Or viable competition to ReFS / storage pools. ;) Don’t know.