Questions about EWF with Compact Flash

  • Thread starter Thread starter Jay
  • Start date Start date
J

Jay

My goal here is to have a stateless machine
- It boots the same every time
- The Compact Flash is never written, preventing wear-
related failures
- I don't need or want any "persistent" data stored on
the CF.

(1) I read somewhere that a RAM EWF overlay is allocated
from non-paged pool, and non-paged pool can be a maximum
of 256 MB. Are these limits correct? Can an EWF RAM
overlay allocate most of that non-paged pool? Assuming
there is enough RAM, how big can the EWF RAM overlay be?

(2) I believe that if the RAM overlay "fills up", you can
get a message such as "Delayed Write Failed. Windows was
unable to save......". Can the user then delete some
files and retry the operation in the same manner as if it
was a floppy drive running out or space?

(3) If Lazy Write is not enabled, is it guaranteed that
the EWF overlay data will not be written to the underlying
media, even if the RAM overlay fills up?

(4) What about shutdown? Can it be guaranteed that EWF
overlay data will not be written to the underlying CF
media on system shutdown?

(5) I'm a little confused about the effects of removable
and non-removable media. If I have a standard CF card (and
did not go through the process with the manufacturer to
get it designated as non-removable), then I can't
partition the CF card and therefore the entire CF will be
protected by EWF. I would need to use the Registry
editing procedure outlined in the article "Using Compact
Flash with the Enhanced Write Filter" to enable the EWF.
Are these assumptions correct ?

(6) Assuming I use the method in in item (5), and it is
time for some software maintenance, I understand that a
EWFMGR commit and disable operation will make my CF
writeable again after the next boot. Does it write all
the overlay data to the CF immediately at the time of the
EWFMGR operation? After the next boot, can I use the
Registry Editing process to re-enable the EWF as before?

I sure would appreciate answers to these questions.
Thank you very much for your help.

Jay
 
1.
I got direct answer from MS developers in this NG that very little memory is
allocated from non-paged pool.
Overlay memory is used from normal paged memory.
So only limit is available memory.

2.
No you can't decrease memory usage. Once allocated by EWF, memory is lost to
you. no matter how many files you delete you will only loose memory.
EWF does not protect file system, but partition itself.

3. Whatever happens data won't be written to your medium.

4. If you don't call commit function then it wont be written to CF during
the shutdown.

5. Don't know I have stumbled few days ago to doc and it seams that you can
partition removable flash?
HOW TO: Using Enhanced Write Filter (EWF) on Removable Media
http://support.microsoft.com/default.aspx?scid=kb;EN-US;814257

What do you think on this subject?

6. When you use commitanddisable, or commit. Data is written during the
graceful shutdown, after FS is closed and disconnected from partition.
And yes you can always enable EWF, after the reboot it will protect your
partition once again.

7. Extra :)
You can find more info on topic how to configure EWF without using the
temporary partition here:
www.xpefiles.com
ramewf.zip


Regards,
Slobodan
 
Slobodan,

Thank you very much for your answers.

You referenced an article in (#5) - I do not think that it
shows that removable CF can be partitioned. Instead, it
shows how to work around the problem by using an extra
hard disk. The image is first deployed to a hard disk
and that disk is used to run through FBA. After FBA is
complete, the temporary partition for EWF has been
deleted. Then the post-FBA disk image can be copied to CF.

I think your procedure (in #7 - ramewf.zip) is much better
because it avoids creating the EWF partition. The
Microsoft procedure seems like a lot of trouble moving
that extra hard disk between systems.

I did find the source of my non-paged pool information.
It is in this Microsoft article:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/xpehelp/html/xeconenhancedwritefilter.asp
This seems to indicate that the EWF overlay area is from
nonpaged pool. I assume the EWF overlay limit would be
less than 256 MB because I doubt XP would allow EWF to
allocate all non-paged pool. (Maybe this article is pre-
SP1 information and things have changed?) The concept
of "paged" pool with a CF/RAM overlay combination doesn't
make much sense to me - there is no place to write the
memory that would have beed swapped to disk in a "normal"
system.

All I can really conclude here is to add as much memory as
possible when we build our system, and probably the memory
size should be twice the size of the CF.

Thanks again for your help.
Regards,
Jay
 
Slobodan,

Yes ! That was the information I needed - thank you very
much for providing the explanation.

Jay

(e-mail address removed)
 
Back
Top