Re: Prevent command prompt from popping up at system startup

Jure,
It looks like you have these requirements.

1 Protect CF card from writes.

2 Flush Cache periodically
-Reading your scenario you are rebooting the machine.
-The rebooting actually is freeing up your cache since you are using RAM
mode.

3 Enable some writes to data files.
-You want to run ewfmgr -commit to commit the data files to disk.

A possible solution is to use FBWF. You'll still need to reboot the machine
to clear the cache but i think you'll have to do it infrequently. The reason
is you can list your data files in a write-through list which allows the
files to be written directly to disk. This won't use up your RAM overlay.

-milong

"Jure" <jure.br@xxxxxxxxx> wrote in message
news:1168332241.000728.147940@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi,

sorry for the delay.

KM wrote:
Jure,

I think 1G RAM is way enough to cover any XPe system that is properly
setup - caches are off, Indexing service and defragmentation
are off, etc. Without providing users to explorer shell functionally and
limiting user ability to mess with the disk under your
custom shell app, you should be pretty safe from the overlay size
standpoint.
Also, what helps is minimizing the footprint of your image. Having less
software added to the OS is obviously minimizing number of
potential components that may be modifying disk clusters on XP.

Although what's not very clear to me is:
- Why do you have such a big CF (4G?) for an image with such
limited functionality?

Actually only 1,5GB of CF is used at present. We have chosen a 4GB CF
because we didn't know know much the final system will be large (and it
wasn't feasable to buy a 2GB CF and then find out it's too small).
Maybe it's better if I explain a little bit more in detail. The custom
application is actually only an entry point to 2 other applications on
the system. One of them is a custom app (written in .Net, not heavy on
writes), the other one is Nobeltec Admiral (www.nobeltec.com). If you
look at the specs of the last one, you'll see that it requires quite a
powerfull machine to operate properly. As far I tested it, it seems it
doesn't perform much writes - mainly it performs reads (charts
data....). So the image has a "limited" functionality, but the
applications that run on it are quite large, so that's the reason of
the (over)sized CF.

Are you writing (or planning on) lots of stuff to the disk from
your custom shell app? Maybe some databases used, etc.?

No. The custom app actually performs some writes (to record and
reproduce the chart of some system's parameters through time), but that
writes should be localized to a small ammount of data.

The same goes for RAM - why have some much RAM available? If
there are heavy apps running at run time there may be more
that we assume here that may fill up the overlay buffers quickly.

Explained before.


- Why do you need to use the easiest solution for the committing
changes in overlay - launching the ewfmgr commit at the
boot time - if your image is custom shell based and user can do only
limited things there?
There must be some other holes in the system you are not
telling us that may be affecting the disk access. If so, it
would be hard to estimate how big the EWF overlay can be.
If not, why not commit the changes when end user makes some
modifications using your custom app (or, better, commit only
the required changes with FBWF or EWF).

Wow. I didn't even know FBFW existed. I quickly read through the
documentation on MSDN and what most caught my attention was the fact
that you can perform live commits (with EWF i think you can do that
only in EWF RAM mode). So, you suggest to use FBFW instead of EWF to
periodically commit the overly and avoid the problem of filling up the
RAM? That seems a very good idea to me, I only have to see what FBFW is
all about and how to set it up.



After all, you can always force your device to reboot on a scheduled
basis to make sure to "clean up" the EWF overlay. Say, you
reboot it every week and you know that overlay doesn't grow more than 1G
within a week.

I'm afraid that can't be done, because users will interract with the
system and it isn't very user friendly to reboot the system when they
are using it.

You should feel the real time range after an
extensive system testing.

Another approach that sometimes is useful and less risky than EWF RAM is
in using RAM disk for storing most of heavy system settings
that don't have to be persistent. This is of course assuming you can
define what settings you want to be persistent and what not.
E.g., if you use IE (not using Explorer shell doesn't mean you don't use
WinInet calls from within your apps) it may sometimes be a
smart decision to move IE Cache to the ram disk storage that will be wipe
out all the session stored data on reboot. The advantage
of the RAM disk approach vs EWF RAM is that you can limit the RAM disk
size (how you handle not enough disk space situation in your
apps is up to you) while with the current EWF implementation there is no
way to limit the overlay size.

--
=========
Regards,
KM



Thanks,
Jure



.

Relevant Pages

  • Re: Prevent command prompt from popping up at system startup
    ... FBFW can indeed be useful to you if you can figure out all the data files that are used/created/modified by the applications you ... If the app is well written, it is going to minimize disk operations and narrow it to ... EWF live commit may also be an option for you but please keep in mind all the restrictions applied to the files to be committed - no ... change in location on the disk, no change in size, etc. Btw, I was under impression you're using EWF RAM mode, aren't you? ...
    (microsoft.public.windowsxp.embedded)
  • Re: Why is HORM restricted to EWF-RAM??
    ... The major reason for using EWF RAM for HORM scenario was that the changes you do while you work with the image that are redirected ... With EWF Disk the changes are redirected to Disk overlay and EWF will pick them up at the ... HORM is enabled. ...
    (microsoft.public.windowsxp.embedded)
  • Re: PNP + EWF Failed getting protected volume with error 1
    ... I was surprised to see Reg RAM EWF not work during the first FBA boot. ... EWF start working only after one reboot is done, ... of your original disk to secondary disk your volumes should be same and same installed driver instances should work since they do ... > The ewfmgr fails with the "failed getting protected volume with error ...
    (microsoft.public.windowsxp.embedded)
  • Re: Low virtual memory
    ... a reboot once in a while would be a good ... The big issue is the limited amount of RAM. ... then you might want to turn off EWF. ... the standard Reg Based EWF, would I be wise to reboot the system every so ...
    (microsoft.public.windowsxp.embedded)
  • Re: EWF in SP2 Not Working
    ... The purpose of the MSDN article is to circumvent the need for a separate EWF ... and to have EWF configured for RAM Reg operation when it finishes ... REG 'Incorrect Function' issue" for more information. ... There are no specific drivers for my Disk Drive type - ...
    (microsoft.public.windowsxp.embedded)