D
Doug G
Now that we have our completed XPE systems in the field, our customer has
suddenly decided that they may not like having "rotating media" on the
factory floor, despite the fact that we based our product on the customer's
own existing device with a hard disk, and the specs for this project were
set about two years ago. Such is life...
I am not sure if this will happen since it will be a costly change, both
from a hardware and s/w development point of view. For one thing, they are
going to have to give up a lot of functionality. Since I have been running
with a 20Gb disk, I did not concern myself with footprint, so I installed a
lot of XP features that they are going to miss if I have to cut the
footprint (my current size is about 150Mb on the boot partition before FBA).
Anyway, since I was always developing for a disk-based system I did not pay
attention to most of the postings here about flash-based systems. I just
need some basic answers to the following so that I can evaluate the overall
feasibility and what it will take to do this. I did look at MSDN and some
archives and have a basic idea of flash specifics, but would like some
clarity.
1) Using an internal "flash disk" device, I can partition it into a
read-only system drive (EWF protection) and a read/write user partition,
correct?
2) I currently use disk-based EWF on our system. When using RAM-based EWF,
is there still that extra EWF-private partition like I have on the
hard-disk-based systems?
3) Does the ewfmgr "-commit" command work with RAM EWF? I guess I thought
that the commit took place on the next reboot, which would be difficult if
the overlay data is in RAM.
4) Do read cycles affect the life of flash memory, or is it only the write
cycles?
Doug G
suddenly decided that they may not like having "rotating media" on the
factory floor, despite the fact that we based our product on the customer's
own existing device with a hard disk, and the specs for this project were
set about two years ago. Such is life...
I am not sure if this will happen since it will be a costly change, both
from a hardware and s/w development point of view. For one thing, they are
going to have to give up a lot of functionality. Since I have been running
with a 20Gb disk, I did not concern myself with footprint, so I installed a
lot of XP features that they are going to miss if I have to cut the
footprint (my current size is about 150Mb on the boot partition before FBA).
Anyway, since I was always developing for a disk-based system I did not pay
attention to most of the postings here about flash-based systems. I just
need some basic answers to the following so that I can evaluate the overall
feasibility and what it will take to do this. I did look at MSDN and some
archives and have a basic idea of flash specifics, but would like some
clarity.
1) Using an internal "flash disk" device, I can partition it into a
read-only system drive (EWF protection) and a read/write user partition,
correct?
2) I currently use disk-based EWF on our system. When using RAM-based EWF,
is there still that extra EWF-private partition like I have on the
hard-disk-based systems?
3) Does the ewfmgr "-commit" command work with RAM EWF? I guess I thought
that the commit took place on the next reboot, which would be difficult if
the overlay data is in RAM.
4) Do read cycles affect the life of flash memory, or is it only the write
cycles?
Doug G