Is there any crash-resistant file system for XPe?

[Guest]

In my first training for XP embedded I learned some details about the EWF. I
want to get a system with XPe and a crash-resistant file system. I can write
protect my CompactFlash with the OS image and with help of the EWF on C:. I
can use the EWF's disk overlay feature for a data partition on an additional
hard disk drive, so that the partition d: is protected against crashes.

But what is about the overlay disk area? Is the EWF sophisticated enough to
detect a defect overlay area and to reset all files within this area after a
system crash which damages the file structure there? Is the dirty bit of D:
the trigger for the EWF to reset the disk overlay area? There must be a file
system in the overlay area cause of the mapped files which can be seen on D:
and are located in the corresponding overlay area. Can Chkdsk repair and
detect files in the overlay area of D:?

I need some background informations to be sure to get a crash-resistant
system. It is ok if data in the overlay area is lost after a system crash,
but the system must be able to save new data in this overlay area after such
a data lost again and again. I plan to avoid any "ewfmgr d: -commit" command
to get this feature. The disk overlay offers permanent temporay data unless a
system crash deletes it. I can store a lot of working data in the overlay
area, reuse this data after system resets and can protect the working of the
whole system after crashes.

Does it work in this way?

It is better to think about a combination from XPe and WinCE?

WinCE could offer a API to XPe so that XPe can use a crash-resistant file
system that runs as part of the RTOS WinCE.

 

[Sean Liming \(eMVP\)]

Typically, EWF on CF uses a RAM overlay. Information in the RAM over lay is
already volital to begin with. Are you planning to use a Disk Overlay
instead of a RAM overlay?
If you are using a Disk Overlay, than you should look into to managing
different overlay levels within the Disk Overlay. Otherwise, EWf doesn't
have a sofisticated file check for corrupt data.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit.

 

[Guest]

I thank you very much for your answer.

Indeed I think about using a Disk Overlay for a big amount of multimedia
files for our infotainment system. This files do not fit into the RAM and can
not be received within few seconds at system's start-up, so they have to be
stored on the HDD.

It seems to be that it is easier to work without the Disk Overlay and to use
the normal Chkdsk to repair corrupt data. Using different overlay levels
seems to be a better protection against system crashes to reduce the possible
amount of corrupt data.

Can Chkdsk repair corrupt data within the overlay area? The files in the
overlay area are mapped to the corresponding file partition. The DOS shell or
Windows Explorer shows them as normal as all other files, so that Chkdsk
should see the files within the overlay area as normal files, too. If Chkdsk
does this, then the using of different overlay levels should be an
improvement against system crashes.

It seems to be a little complicated from a pure technical point of view.
What is about real crash-resistant file system for XPe that doesn't need a
Chkdsk? I cannot imagine that all XPe applications do not need a lot of data
files to be stored on a HDD. A Chkdsk can increase the start-up time, so that
it is bad for a real embedded system. A crash-resistant file system can avoid
this. Is my application so special or system crashes so impossible in
embedded enviroments?

Is there any solution like Reliance(tm) file system from DataLight for XPe?
Is it possible to use a transactional file system like this under WinCE and
to provide this feature for the XPe system as task of WinCE ?