EWF with "Lazy write"

  • Thread starter Thread starter Jes Holm
  • Start date Start date
J

Jes Holm

Dear Group,

I would like to reduce the writes to a DOM (Flash IDE drive) by using the
EWF.

I assume that this is done by enabling "Lazy write", but I have not been
able to find any information on using "Lazy write".

If I configure the EWF Partition size to e.g. 2048KB and set the Overlay
Type to "RAM". Will file I/O then be "cached" by the 2048KB RAM and only
written to the physical disk when the system is idle or the cache is full?

Best regards,
Jes Holm
 
Hi Jes,

Lazy writes have nothing in common with EWF.
You can't set how much memory EWF will use. It will grow until all your memory is consumed and your system crash if you do not
design it properly to reduce write to disk (overlay).

http://msdn.microsoft.com/embedded/community/community/tips/xp/ramewf/default.aspx
http://groups.google.com/groups?hl=en&lr=&c2coff=1&[email protected]
http://msdn.microsoft.com/library/d..._66a07114-953e-49aa-bebf-f9b4ca60a6dd.xml.asp

I hate being like a parrot regarding EWF so read trough:
http://groups.google.com/groups?hl=...a=group=microsoft.public.windowsxp.embedded.*

Use google groups to search for already answered questions. (Add this to your favorites)
http://groups.google.com/groups?hl=...F-8&group=microsoft.public.windowsxp.embedded

Regards,
Slobodan
 
Slobodan Brcin (eMVP) said:
Hi Jes,

Lazy writes have nothing in common with EWF.
You can't set how much memory EWF will use. It will grow until all your
memory is consumed and your system crash if you do not
design it properly to reduce write to disk (overlay).

Actually, the article
http://msdn.microsoft.com/embedded/community/community/tips/xp/ramewf/default.aspx
says that "the maximum size of an EWF overlay is the size of the protected
volume in addition to a small percent for overhead". Wouldn't this mean that
if I am protecting a 256Mb disk partition, then the EWF usage of RAM should
never exceed 256Mb? It also says "The EWF RAM usage reaches maximum size if
all sectors on the protected volume are overwritten in a single boot". This
is obviously very unlikely since most of my original XPE image files are
only read, not written. So it seems like the maximum EWF usage of RAM can be
safely allowed for, especially if the "Optimize writes" EWF option is
selected.

Am I missing something here?

Doug Gordon
 
Hi Doug,
Actually, the article
http://msdn.microsoft.com/embedded/community/community/tips/xp/ramewf/default.aspx
says that "the maximum size of an EWF overlay is the size of the protected
volume in addition to a small percent for overhead". Wouldn't this mean that
if I am protecting a 256Mb disk partition, then the EWF usage of RAM should
never exceed 256Mb?
Correct.

It also says "The EWF RAM usage reaches maximum size if
all sectors on the protected volume are overwritten in a single boot". This
is obviously very unlikely since most of my original XPE image files are
only read, not written.

This would be worst theoretical case. If you for instance manage to defrayments all files on disk, by moving them around. (You won't
do that, right :-) )
So it seems like the maximum EWF usage of RAM can be
safely allowed for, especially if the "Optimize writes" EWF option is
selected.

Am I missing something here?

You are missing the one thing I guess. And that is that RAM EWF does not care what size you specify in max size allowed for EWF,
since it is used only for disk overlay allocation.
So you can put 0, 2MB or 1024MB it will all be same for EWF (it will be ignored).

Regards,
Slobodan
 
Doug,
Actually, the article
http://msdn.microsoft.com/embedded/community/community/tips/xp/ramewf/default.aspx
says that "the maximum size of an EWF overlay is the size of the protected
volume in addition to a small percent for overhead". Wouldn't this mean that
if I am protecting a 256Mb disk partition, then the EWF usage of RAM should
never exceed 256Mb? It also says "The EWF RAM usage reaches maximum size if
all sectors on the protected volume are overwritten in a single boot". This
is obviously very unlikely since most of my original XPE image files are
only read, not written.

This all is correct.
So it seems like the maximum EWF usage of RAM can be
safely allowed for, especially if the "Optimize writes" EWF option is
selected.

I did not get how you connected the "Optimize writes" to the EWF RAM usage.
Whenever you do any write optimizations it may make things worse with EWF RAM. However, it will be limitted by the protected storage
size anyway.
 
KM said:
I did not get how you connected the "Optimize writes" to the EWF RAM usage.
Whenever you do any write optimizations it may make things worse with EWF
RAM. However, it will be limitted by the protected storage
size anyway.

Sorry, I was going from memory (which is often faulty these days). I meant
to say the "Use Less Overlay Space" setting for EWF should reduce its RAM
usage, correct?

Doug
 
Slobodan Brcin (eMVP) said:
You are missing the one thing I guess. And that is that RAM EWF does not
care what size you specify in max size allowed for EWF,
since it is used only for disk overlay allocation.
So you can put 0, 2MB or 1024MB it will all be same for EWF (it will be ignored).

I think I understand this. But if I have 512Mb of physical RAM on my PC, of
which less than 128Mb is used by my actual XPE system and application, and a
256Mb protected disk partition, it should be impossible for me to run out of
memory for either my application or the EWF overlay. Correct?

Doug
 
Hi Doug,
I think I understand this. But if I have 512Mb of physical RAM on my PC, of
which less than 128Mb is used by my actual XPE system and application, and a
256Mb protected disk partition, it should be impossible for me to run out of
memory for either my application or the EWF overlay. Correct?

YOU CAN'T RUN OUT OF MEMORY.

Regards,
Slobodan
 
Doug,
Sorry, I was going from memory (which is often faulty these days). I meant
to say the "Use Less Overlay Space" setting for EWF should reduce its RAM
usage, correct?

I have no idea how to use this option with registry configured RAM EWF.
Also idea behind this is that when every clump changes EWF will check its content to original content written on physical medium. In
case that they are same EWF will release some piece of memory.
This mean that if you have some file with zeroes in it (for instance) and then you write some data in it overlay mem usage will
increase, but if you write zeroes back to it then it will decrease.
Unfortunately this slows writes because instead of making only changes in RAM EWF need to read each clump from physical medium for
comparation.

So you would have much slower write performance, and I doubt that anything would change with real usage done by os and applications.

BTW: Does any one know if this option is working with RAM EWF and how to enable this option in reg config EWF?

Anyhow I wonder why MS choose to continue to force one component for both disk and ram based overlays since it is obvious that this
make real confusion to many developers.

Regards,
Slobodan
 
Doug,
RAM. However, it will be limitted by the protected storage

Sorry, I was going from memory (which is often faulty these days). I meant
to say the "Use Less Overlay Space" setting for EWF should reduce its RAM
usage, correct?

I don't know. Even though the documentation does not say it is Disk Overlay related only I guess it may be.
In any case, this is not for limiting the EWF RAM usage. It is just an optimization for a regular usage (see Slobodan's explanation
on how it works).
 
Slobodan,
Doug,


I have no idea how to use this option with registry configured RAM EWF.
Also idea behind this is that when every clump changes EWF will check its content to original content written on physical medium. In
case that they are same EWF will release some piece of memory.
This mean that if you have some file with zeroes in it (for instance) and then you write some data in it overlay mem usage will
increase, but if you write zeroes back to it then it will decrease.
Unfortunately this slows writes because instead of making only changes in RAM EWF need to read each clump from physical medium for
comparation.

So you would have much slower write performance, and I doubt that anything would change with real usage done by os and applications.

BTW: Does any one know if this option is working with RAM EWF and how to enable this option in reg config EWF?

Anyhow I wonder why MS choose to continue to force one component for both disk and ram based overlays since it is obvious that
this make real confusion to many developers.

I agree.. And especially the documentation should make it more clear the difference between Disk and RAM overlays.
It is now not clear what options are applied to what overlay type (or to both).
The optimization options all come to the registry multi-string value PVOptimize that is handled by EWF driver but not documented.
 
Hi Slobodan,

Thank you very much for you answer.
Lazy writes have nothing in common with EWF.
Actually I was referring to the setting "Enable Lazy Write" in the EWF
component.

But as far I as I have understod I can not use EWF in my setup.

Best regards,
Jes Holm
 
Hi Jes,

You might be able to use disk overlay based EWF, or you can redefine your requirements to match RAM EWF usage.

Regards,
Slobodan
 
Back
Top