EWF File Persistence Corruption

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

Guest

I'm using EWF RAM and an additional read/write volume for ini file
persistence. The problem is, once in a while the system could be powered off
during a write and corrupt the file. Has anyone encountered this? I need some
parameters to be persistent.
 
Tim,

You are writing the file to unprotected partition? Usually ini files are small. Does it take a long time for your apps to write the
file?

Anyway... probably only hardware options can give you a high assurance that the file writes would be finished. UPS?
 
KM,

Went to XPE and EWF RAM to remove UPS and XP Pro.

The ini file is only 4K and the problem doesnt happen often. But, it does
happen occasionally and the customer could potentially lose information when
corruption occurs - such as how many x-ray scans a system has taken.

Might have to use separate mechanical counters for critical info.

Thanks.
 
Tim,

You did not answer the first question. Are you writing the file to an unprotected partition?
Or you writing it to protected one and then trying to commit the changes?

If the problem happens during the write operation to the disk.. Well, you have a conceptual problem rather the a software issue. You
want to dump some ram content (some variable blocks in memory) to a persistent storage. Unless you have very fast persistent storage
or hardware protection against a power loss, you may not fix the problem completely.
 
Is the unprotected partition NTFS or FAT?

David
KM said:
Tim,

You did not answer the first question. Are you writing the file to an
unprotected partition?
Or you writing it to protected one and then trying to commit the changes?

If the problem happens during the write operation to the disk.. Well, you
have a conceptual problem rather the a software issue. You
want to dump some ram content (some variable blocks in memory) to a
persistent storage. Unless you have very fast persistent storage
or hardware protection against a power loss, you may not fix the problem
completely.

--
Regards,
KM, BSquare Corp.

PS. You anyway better use more reliable FS. Hope you went with NTFS on
unprotected partition.
Click to expand...
 
Tim:

Yes, I've seen his and still experience this.

Do a google groups search for "EWF chkdsk dirty" to get see old threads on
this.

HTH... Doug
 
Km,

I'm writing to an unprotected NTFS as you probably expected. I agree with
you completely. There is only so much you can do in software with the
provided hardware.
Thanks for you response

tim
 
Hi Tim,

Actually it is more problem how you perceive your hardware and software approach that you take.
You can use one RAW partition and do direct data saves optimized for data type that you log. You can do cyclic logging to reduce
write wearing problems and to allow to previous data if you had problems with last writes, etc.

So basically I never choose NTFS or FAT for critical log data but always try to go directly as possible and to remain in control of
things.

Regards,
Slobodan
 
Tim,

In any case you may want to disable the write cache option on disk. Then no more than one sector can be lost by power down during
write operation.
 
How about writing the new ini file to a temp file, then delete the old file
and rename.

......You'd probably need some extra recovery code, but it would mean that
you always had either the old file or the new one, the filesystem.
 
Hi Mark,

This would not guarantee that transaction is 100% correct :-(
You must consider FS and disk caching also.

Regards,
Slobodan
 
Hi,

I think Mark's solution is correct if you force
disk flushing (using FlushFileBuffers API) after
writing the temp file and before deleting the old
file. The subsequent FS operations (delete, rename)
should be atomar (at least for NTFS), so there will
be no danger for corruption.

Regards,
Bernhard
 
Hi Bernhard,

Perhaps, but I would not rely on this.
If he need to use FS I would suggest him to always have two files with integrity check in them and serial number of write.

So he should have file1.cnf and file2 cnf and he can always write data to older file based on serial number. When reading data he
should read both files and based on integrity check and serial increment number he can determine what data to use.

Regards,
Slobodan
 
Agreed if disk caching is disabled it should be ok. However, depending on
performance it may not be possible to disable disk caching.

With all IO operations there is going to be a risk of corruption, if taking
software based steps doesn't solve the problem for you, then you may have a
backup power system.

Cheers Mark
 
Back
Top