To MS: Regarding EWF, and FBA on CF.

[Slobodan Brcin]

Just one idea for improvement of EWF functionality.

Consider the scenario where someone want to run FBA directly on CF.
Some people are afraid to do this because they think that this will damage
their CF, because of extensive writes done during the FBA.
What would happen if EWF was enabled during FBA process we already know that
this is possible. We would protect CF but after FBA reboots changes would be
lost.
Now what would happen if we called commit during each boot while FBA is in
progress (for multiple reboots scenario).
All changes that are accumulated in ram overlay would be written only once
to CF sectors during the file system close phase (before reboot).
This could be probably accomplished by calling ewfmgr.
Also we would gain FBA speed improvement, since slow write operation is done
only once during the reboot.

Now what I suggest is very simple to implement in next version of EWF
driver.
To avoid calling ewfmgr. EWF driver should be able to read some EWFCommit
flag from registry, this flag would be enabled from TD, and removed by
developer (or FBA) after the installation is done.


I would like to hear opinions of this group on this subject?


Regards,
Slobodan

 

[KM]

Slobodan,

This a good idea to improve FBA process on CF.

However, I've seen that FBA process is very memory consuming. Also, image
setup things may be applied to many, many files and it may blow up the EWF
overlay cache size. I guess that adding EWF in the picture while FBA is
setting up a target device may increase the risk of consuming all available
memory (especially, since you are not going to use pagefile with EWF) and
you may see known "Delayed Write Failed" messages. That will probably break
completely the FBA process and may damage CF.

KM

SB> Just one idea for improvement of EWF functionality.

SB> Consider the scenario where someone want to run FBA directly on CF.
SB> Some people are afraid to do this because they think that this will
SB> damage their CF, because of extensive writes done during the FBA.
SB> What would happen if EWF was enabled during FBA process we already
SB> know that this is possible. We would protect CF but after FBA
SB> reboots changes would be lost.
SB> Now what would happen if we called commit during each boot while FBA
SB> is in progress (for multiple reboots scenario).
SB> All changes that are accumulated in ram overlay would be written
SB> only once to CF sectors during the file system close phase (before
SB> reboot).
SB> This could be probably accomplished by calling ewfmgr.
SB> Also we would gain FBA speed improvement, since slow write operation
SB> is done only once during the reboot.

SB> Now what I suggest is very simple to implement in next version of
SB> EWF driver.
SB> To avoid calling ewfmgr. EWF driver should be able to read some
SB> EWFCommit flag from registry, this flag would be enabled from TD,
SB> and removed by developer (or FBA) after the installation is done.


SB> I would like to hear opinions of this group on this subject?


SB> Regards,
SB> Slobodan

 

[Slobodan Brcin]

You are right, but I though about systems with enough memory.

Regarding "Delayed Write Failed" this is not dangerous message when EWF is
enabled, since this is indication that EWF started to reject new write
requests. This can't damage your CF, only thing is that FBA will fail. And
when someone sees this message then he will know that he can't use this
approach.

Thanks, for comment.
Slobodan