Volume Filter

NTDEV
1

I was under the impression that volsnap is volume class filter even for Windows server 2003/8 till I read post - http://www.osronline.com/showThread.CFM?link=113618.

I would like to know what other changes got introduced to Windows server 2008.
I could see some new drivers got introduced - volmgr (ftdisk/dmio equivalent), volmgrx, fvevol, rdyboost. What each of these for ?

I am developing volume filter driver for volume caching (not in memory) purpose. So, there is possibility that some data would be in cache store and some on the volume.

I believe to support volume snapshot feature for the cache enabled volume, I need to handle some volsnap IOCTLs in the filter.
I may need to sync volume from cache to process IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES and that too quickly.
Please correct me if I am wrong.

From some earlier posts, it seems it is recommended to develop volume filter in KMDF way. I don’t see many advantages using KMDF over WDM when writing filter as opposed to function/bus driver. I am familiar with WDM and not KMDF. Please provide opinion on this.

2

> I could see some new drivers got introduced - volmgr (ftdisk/dmio equivalent),

FtDisk equivalent, and also the plugin point for volmgrx which is no more a standalone driver.

It is a PnP bus driver which creates PDOs for volumes (i.e. logical disks), they hang off the root device which is root-enumerated, their relation to underlying physical disks (i.e. LUNs) and partitions is private to this FtDisk/VolMgr driver, is NOT represented in Device Manager (and thus in PnP at all) and requires the physical disk device numbers matching to be discovered.

volmgrx,

DmIo.

fvevol,

Bitlocker. FVE = Full Volume Encryption.

rdyboost.

ReadyBoost. This creates a paging-like swap/prefetch/cache file on a flash drive, which will be much faster on random access then the HDD (even on USB 2 flash drives).

I believe to support volume snapshot feature for the cache enabled volume, I need to handle some volsnap
IOCTLs in the filter.

From 2003 up, VolSnap is a FD for Volume class (and it always was a bus driver which created PDOs for exposed snapshots, these PDOs were hanging off the volume devnode), while FtDisk/DmIo/VolMgr are PDs.

So, you can have lower filters between FDO (VolSnap) and PDO (VolMgr). All of the above things like FveVol are there.

So, if you want your cached view of the volume (which is a drive letter for users) to support VSS snapshots for backup and the Previous Versions feature, you must be below VolSnap. And, if you want BitLocker to be able to encrypt your cached volume, you must be below FveVol.

I may need to sync volume from cache to process IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES

You will not see this below VolSnap. VolSnap is the final destination for it.

More so, this is OK. This IOCTL is only intended for snapshot creation to include the latest in-cache updates, in order for the snapshot to be consistent. For such a purpose, it is only needed that the FSD will see this IOCTL.

If you want durability and not just consistence of the snapshot - then this is a wrong IOCTL, and what you need is good old MJ_FLUSH IRP/FlushFileBuffers. This propagates till the hard drive’s internal cache by using a special SCSI command to implement it in the storage port.

From some earlier posts, it seems it is recommended to develop volume filter in KMDF way.

You can develop it using modern KMDF (which supports guaranteed forward progress), or using WDM with DiskPerf as a boilerplate.

It’s a question of taste. KMDF is maybe simpler after you will pass some learning curve and learn the basics.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Thanks Maxim for detailed explanation

If my filter sits below fvevol,I would be able support encryption as well as volume snapshots for the cached volume. I will try modifying INF for the same.