Partilhar via

Reduce Exposure Time and User Downtime when Servicing a Write-Filter Enabled Image

  • Artigo

Those who service images with write filters are aware that the combination of applying updates and having write filters is one with several concerns and complexities. Amongst those concerns are exposure time and user downtime. What do I mean? I will explain in the following paragraphs.

Servicing a write-filter enabled image goes roughly as follows:

  1. Disable write filter
  2. Reboot (so that disabling the write filter goes into effect)
  3. Download the update
  4. Install the update
  5. Re-enable the write filter
  6. Reboot (so that the re-enabling of the write filter goes into effect)

What we care about here is that the write filter is disabled throughout Steps 3 and 4, which has two negative implications:

  1. Exposure Time: The system is in a state where any write will be persisted, or in other words, the system is exposed.
  2. User Downtime: Users are expected to not do anything during this duration to prevent persisting of an undesirable state. Often IT Pros will ensure that the user is locked out through this duration.

Although you may fail to completely eliminate the above two problems, you can at least take measures to mitigate them. Like what? Just move Step 3 (Download the update) to the beginning of the 6-step process. To be more explicit, the new 6-step process will be as follows:

  1. Download the update
  2. Disable write filter
  3. Reboot (so that disabling the write filter goes into effect)
  4. Install the update
  5. Re-enable the write filter
  6. Reboot (so that the re-enabling of the write filter goes into effect)

Now, the update will be downloaded while the write filter is still enabled leaving only the installation step (Step 4) to take place while the write filter is disabled. Subsequently, the exposure time and the user downtime will be limited to just the installation step.

But wait… the update downloaded at Step 1 will no longer be there by the time we reach Step 4 to start the installation. That is correct-----unless the update is downloaded into an unprotected location in the filesystem. In the case of FBWF, you can easily add a particular folder to the exclusion list and have the update files downloaded there. As for EWF, you will need an unprotected partition to download the updates into. Subsequently, this approach may not work well for everyone who’s using EWF.

In closing, I should note the obvious: The implementation specifics have not been spelled out in this article as they vary depending on customer needs and the specific technologies used for servicing. Lastly, I will attempt a quick one-sentence recap: To reduce exposure time and user downtime, download the update files into an unprotected location, so that the write filter only needs to be fully disabled during the installation.

- Norris

Technorati Tags: XPe,Embedded Standard

Comments

  • Anonymous
    January 04, 2010
    Nice idea.  I'd like to go one step further and reduce deployment steps to eliminate reboots altogether using scripting. on the backend: before downloading the update, prepare a list of all the files and paths that are modified by the update and integrate these into a batch file or script which has the ability to commit each of the modified files. client side:
  1. download update
  2. install update
  3. run commit script Next time user reboots (at his or her leisure) the download and all temp files are wiped clean.  This way the only disruption time is the time it takes to download, install and run the commit script.