| Author |
Message |
Tim
Guest
|
 Posted:
Thu Jan 13, 2005 1:57 am Post subject:
EWF File Persistence Corruption |
|
|
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 |
|
| Back to top |
|
 |
KM
Guest
|
| Posted:
Thu Jan 13, 2005 2:59 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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?
--
Regards,
KM, BSquare Corp.
| Quote: | 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 |
|
|
| Back to top |
|
|
Tim
Guest
|
| Posted:
Thu Jan 13, 2005 3:09 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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.
"KM" wrote:
| Quote: | 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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Thu Jan 13, 2005 3:24 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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.
| Quote: | 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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
David Ditch
Guest
|
| Posted:
Thu Jan 13, 2005 3:24 am Post subject:
Re: EWF File Persistence Corruption |
|
|
Is the unprotected partition NTFS or FAT?
David
"KM" <konstmor@nospam_yahoo.com> wrote in message
news:%23LvFjTP%23EHA.3236@TK2MSFTNGP15.phx.gbl...
| Quote: | 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.
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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
Doug Hoeffel
Guest
|
| Posted:
Thu Jan 13, 2005 3:39 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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
"Tim" <Tim@discussions.microsoft.com> wrote in message
news:E63234A5-1F75-4505-9A0D-AAFE266ECA40@microsoft.com...
| Quote: | 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 |
|
|
| Back to top |
|
|
Tim
Guest
|
| Posted:
Thu Jan 13, 2005 3:51 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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
"KM" wrote:
| Quote: | 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.
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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
Tim
Guest
|
| Posted:
Thu Jan 13, 2005 3:51 am Post subject:
Re: EWF File Persistence Corruption |
|
|
NTFS
"David Ditch" wrote:
| Quote: | Is the unprotected partition NTFS or FAT?
David
"KM" <konstmor@nospam_yahoo.com> wrote in message
news:%23LvFjTP%23EHA.3236@TK2MSFTNGP15.phx.gbl...
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.
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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
Slobodan Brcin (eMVP)
Guest
|
| Posted:
Thu Jan 13, 2005 4:18 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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" <Tim@discussions.microsoft.com> wrote in message news:70E44A34-AFB0-4C9D-AE65-37E3DE70EAC5@microsoft.com...
| Quote: | 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
"KM" wrote:
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.
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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
KM
Guest
|
| Posted:
Thu Jan 13, 2005 5:00 am Post subject:
Re: EWF File Persistence Corruption |
|
|
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.
--
Regards,
KM, BSquare Corp.
| Quote: | 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
"KM" wrote:
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.
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.
"KM" wrote:
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?
--
Regards,
KM, BSquare Corp.
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
|
|
|
| Back to top |
|
|
Mark Ison
Guest
|
| Posted:
Thu Jan 13, 2005 4:25 pm Post subject:
Re: EWF File Persistence Corruption |
|
|
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.
"Tim" <Tim@discussions.microsoft.com> wrote in message
news:E63234A5-1F75-4505-9A0D-AAFE266ECA40@microsoft.com...
| Quote: | 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 |
|
|
| Back to top |
|
|
Slobodan Brcin (eMVP)
Guest
|
| Posted:
Thu Jan 13, 2005 7:41 pm Post subject:
Re: EWF File Persistence Corruption |
|
|
Hi Mark,
This would not guarantee that transaction is 100% correct :-(
You must consider FS and disk caching also.
Regards,
Slobodan
"Mark Ison" <mark@no_spam.com> wrote in message news:cs5lr3$10a$1$830fa7a5@news.demon.co.uk...
| Quote: | 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.
"Tim" <Tim@discussions.microsoft.com> wrote in message
news:E63234A5-1F75-4505-9A0D-AAFE266ECA40@microsoft.com...
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
|
|
|
| Back to top |
|
|
Bernhard
Guest
|
| Posted:
Thu Jan 13, 2005 8:13 pm Post subject:
Re: EWF File Persistence Corruption |
|
|
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
Slobodan Brcin (eMVP) wrote:
| Quote: | Hi Mark,
This would not guarantee that transaction is 100% correct :-(
You must consider FS and disk caching also.
Regards,
Slobodan
"Mark Ison" <mark@no_spam.com> wrote in message
news:cs5lr3$10a$1$830fa7a5@news.demon.co.uk...
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.
"Tim" <Tim@discussions.microsoft.com> wrote in message
news:E63234A5-1F75-4505-9A0D-AAFE266ECA40@microsoft.com...
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
|
|
|
| Back to top |
|
|
Slobodan Brcin (eMVP)
Guest
|
| Posted:
Thu Jan 13, 2005 8:57 pm Post subject:
Re: EWF File Persistence Corruption |
|
|
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
"Bernhard" <bdegel@init-ka.de> wrote in message news:1105629232.806448.138670@c13g2000cwb.googlegroups.com...
| Quote: | 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
Slobodan Brcin (eMVP) wrote:
Hi Mark,
This would not guarantee that transaction is 100% correct :-(
You must consider FS and disk caching also.
Regards,
Slobodan
"Mark Ison" <mark@no_spam.com> wrote in message
news:cs5lr3$10a$1$830fa7a5@news.demon.co.uk...
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.
"Tim" <Tim@discussions.microsoft.com> wrote in message
news:E63234A5-1F75-4505-9A0D-AAFE266ECA40@microsoft.com...
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
|
|
|
| Back to top |
|
|
Mark Ison
Guest
|
| Posted:
Thu Jan 13, 2005 9:37 pm Post subject:
Re: EWF File Persistence Corruption |
|
|
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 to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in