RAM based EWF filling up with OS writes

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

HI All,

I have a disk based embedded product that we want to protect against
corruption during unexpected power loss using the EWF provided with XP
embedded. Given the extensive API associated with the EWF it is obvious a lot
of thought has gone into this aspect of the XP embedded product, and on the
face of it it seems well done.

With that said, it seems we have uncovered a fatal flaw in the EWF's
execution. While using the EWF in RAM mode, it gradually fills up with
various OS system writes. I have redirected every conceivable write to an
unprotected partition as outlined on the following Microsoft webpage -

http://msdn.microsoft.com/library/d...lp/html/xeconewfperformanceconsiderations.asp

Examples of troublesome writes still found by using FileMon.exe are as
follows:

System:4 C:\$LogFile
System:4 C:\$Mft
System:4 C:\$Directory
C:\Windows\system32\wbem\Repository\FS\MAPPING1.MAP
C:\Windows\system32\wbem\Repository\FS\MAPPING2.MAP
C:\Windows\system32\wbem\Repository\FS\INDEX.MAP

Our application NEEDS to stay up and running for months at a time, and we
CANNOT tolerate roboots to flush the EWF.

We also cannot use a disk-based EWF because it is a headless system and we
have no way of "pressing F8" at boot time to select a restore option.

If we cannot find a way around this we may have to go with another embedded
OS as a solution, one that is a "true" embedded OS meant to run without
constant reboots just to "clean things up".

Best Regards and thanks for any insight/info you can provide.

Bob C
 
What file system is on the protected partition? My understanding is that
FAT32 is a better choice because NTFS has a lot more housekeeping that goes
on and can cause more writes to the partition than you might be expecting.

Doug G
 
Have you turned off all the OS stuff like: Background disk defrag; IIS
logging; IE caching?

--
Regards.
Mark K Vallevand (e-mail address removed)

Beer is living proof that God loves us and wants us to be happy.
- Benjamin Franklin


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
 
Doug,

We have to use NTFS. I tried FAT32 just for academics sake, and we still
were filling up the RAM EWF. I think there are some things that are just
GOING to get written to the EWF, and if our application is left running long
enough (months at a time) we will run out of RAM.

Interestingly enough, I purposefully choked up the RAM EWF with big file
writes to the protected volume, and even though the OS complained about
things (like not being able to write to the event log which had been moved to
an unprotected partition) our application still worked. Doesn't give me the
warm fuzzies though. . . .

Regards,

Bob C
 
Mark,

I have redirected every conceiveable writes to an unprotected volume, and
the RAM EWF still slowly, but surely fills up over time.

I have spoken with several "experts" about this issue, and they have no
solution, and I think Microsoft will not have one either. I just want to get
this on the plate so others know of this limitation with XP Embedded, or know
of some trick to get around this.

It would be great if these system writes could be made to go through the
write filter instead of filling it up. . . .

Regards,

Bob C
 
Hmmm. We've run some very very long term tests and don't see the EWF cache
filling up.

We've done some work to make more memory available. XP does allocate memory
for some pools that are excessively large.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\NonPagedPoolSize set to 1024

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\PagedPoolSize set to 1024

If not set, they default to rather large numbers. If either memory pool
needs to expand, they will do so dynamically. So, we've seen no ill
effects. This change alone made about 70mb more memory available to
application programs and EWF cache. It was headroom we really needed.

--
Regards.
Mark K Vallevand (e-mail address removed)

Beer is living proof that God loves us and wants us to be happy.
- Benjamin Franklin


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
 
Back
Top