Overlay for Unified Write Filter (UWF) (Standard 8)
December 16, 2014
Review the overlay feature of the Unified Write Filter (UWF) for Windows Embedded 8 Standard (Standard 8).
Unified Write Filter (UWF) protects the contents of a volume by redirecting all write operations on that volume to the overlay, which is a virtual representation of the changes to the volume. Conceptually, an overlay is similar to a transparency overlay on an overhead projector. Any change that is made to the transparency overlay affects the projected picture as it is seen by the viewer. However, if the transparency overlay is removed, the underlying picture remains unchanged.
In a UWF protected system, UWF creates a single overlay, which contains information about writes to all protected volumes on a system. The overlay supports up to 16 terabytes of protected volumes.
Overlay Storage
You can configure UWF to store the overlay either entirely in RAM (RAM-based), or to store the overlay in a pre-allocated file on the system volume (disk-based).
All information in the overlay is lost after a device restarts or experiences a power loss, regardless of how the overlay is stored.
RAM-Based Overlay
In a RAM-based overlay, all overlay information is kept in system memory. Because RAM-based overlays reduce access to the physical volume, they can reduce wear on write-sensitive media. RAM-based overlays can be used with read-only media or in devices that use Hibernate Once/Resume Many (HORM).
As applications continue to write to protected volumes, a RAM-based overlay consumes available free RAM until the overlay reaches a specified maximum size or the system either runs out or reaches critically low levels of available RAM, which requires that the system be restarted. Because RAM is typically much more expensive than disk space, available RAM usually limits how long your system can operate before needing to be restarted.
Disk-Based Overlay
In a disk-based overlay, UWF uses a pre-allocated file created on the system volume to increase the available space for the overlay. Disk-based overlays cannot be used with HORM.
The maximum size of the overlay is limited to the size of the disk file. The disk file does not dynamically grow in size, but must be pre-allocated on the volume.
Overlay Size
The overlay is initially created the first time the file system mounts a volume. Each time that UWF redirects a write attempt to the overlay, the disk sectors that would be modified are copied to the overlay. Because file systems do not access individual sectors on a volume, but rather clusters of sectors, the entire cluster that would be modified is copied to the overlay.
When the file system erases or deletes files that do not exist on the protect volume, UWF removes unneeded clusters from the overlay and returns the freed resources to the available pool. This primarily affects the overlay size when temporary files are created and then deleted.
Disk-based overlays require a maximum overlay size of at least 1024 KB.
Overlay Thresholds and Notifications
Because overlays grow in size and consume available resources as applications continue to write to protected volumes, you may want to have your device notify the user when available resources are critically low. You can configure UWF to write an event to the error log when the size of the overlay reaches or exceeds a configurable percentage of available resources. UWF uses Event Tracing for Windows (ETW) to write the event message.
You can configure a warning threshold level and a critical threshold level for the overlay size in UWF. If the overlay size is reduced to below the threshold levels, possibly from deleting temporary files, UWF writes an event to indicate that the overlay size has returned to a normal operating size.
Important
For WE8S (and WE8I), the following actions and events add to overlay usage:
- Changes and deletions in excluded directories, excluded files, or excluded registry items.
- File and registry commits.