I’m looking into the implications of mounting a system boot volume for
offline maintenance using Windows PE.
I was thinking that if the storage stack normally has a filter driver, like
for real-time replication, virus scanning, compression, or deduplication,
the state of a volume could be compromised if it’s mounted from an OS that
doesn’t have these filter drivers. Minimally, the real OS Image will have to
do some sort of resync operation when the volume is again mounted by a
properly filtered storage stack.
So my first question, is there any way for a filter driver to detect if a
volume (NTFS file system) has been mounted unexpectedly? Something like a
last mount timestamp or serial number? Certainly the uglier scenario is a
volume is mounted and some synchronized data structure is not kept in sync,
and it’s not detected that things are now out of sync. For real-time
replication, this would imply the replica now has non-matching blocks, like
in potentially the free space bitmap.
Or, do people think that once you install a filter, it’s an operationally
invalid thing to then mount the volume with a non-filtering OS flavor?
For some cases, I could see the argument that using advanced filters on the
system boot volume is not a valid thing to do, although I could also see the
argument that if you really want real-time replication for disaster
recovery, the boot volume seems important to replicate.
Opinions from you storage filter driver writers?
Jan