Protect Multiple Volumes in a Hibernate Once/Resume Many Configuration (Standard 7 SP1)
7/8/2014
One of the limitations of implementing a Hibernate Once/Resume Many (HORM) environment on your device is that all the partitions on the system must be protected by Enhanced Write Filter (EWF). Because the file system caches information about each partition on the system, that file system information is loaded when the system starts from the hibernation file. A write may not to be captured in the hibernation file. If that occurs, the system may be corrupted on startup because of the mismatch between the hibernation image and the contents of the partition.
For example, on a system with two partitions, drive C and drive D, you enable EWF. However, EWF is only enabled for drive C. Drive D is not protected by EWF.
When you create the hibernation file, information about the contents of drives C and D are included in the hibernation file. This is because the file system caches information about the attached volumes in the system. When the system starts, it loads information in the hibernation file about both drive C and drive D. Then you delete several files from drive D. Because drive D is not protected by EWF, these files are deleted from the system.
The system restarts, and loads information from the hibernation file. Because the hibernation file still includes cached information about the contents of drive D, that information is loaded into RAM. Because the files that you deleted from drive D no longer exist in the system, the contents of the system's RAM and the contents of drive D do not match. The system now potentially becomes corrupted. This is why EWF must protect all partitions in a Hibernate Once/Resume Many environment.
However, you can flush the contents of a nonboot volume from system cache by dismounting the volume before you create the hibernation file.
Dismounting Volumes Before Hibernation
To make sure that the write cache for a volume is cleared before you create the hibernation file, you must dismount the volume. When a volume is dismounted, the write cache for that volume is flushed from system memory. It is then safe to create the hibernation file. By dismounting any volumes you do not want protected, you can make sure that any write cache data from the system is not written to the hibernation file.
Note
This does not guarantee that applications do not have cached state information from the dismounted volumes. It is the responsibility of the designer of the Standard 7-based system to monitor applications and verify that they contain no state information about the volume.
When the system starts from the hibernation file, no information is loaded about the volumes you dismounted. The system rediscovers additional volumes every time that the system starts from the hibernation file. Because there is no information about the volume that is loaded from the hibernation file, you can safely write to an unprotected volume.
To dismount a volume, you can create an application that locks and dismounts the volume, and then create the hibernation file.
See Also
Tasks
Programmatically Dismount Volumes
Other Resources
Use an Unprotected Volume in a Hibernate Once/Resume Many Environment