Damaged files after rebooting

Hello !

We have measurement system on QNX 4.25 with some processes runing. While
working some measurement files are created. I can acces them, and I can
check they are proper. I can even copy them to removable media like ZIP
disk. But after switching off (exiting photon, exiting user, then power
down computer), and switching on again some random files are damaged. It
looks like they aren’t phisically witten to disk. When developing this
system even some system files were damaged in this manner (pdm, pfm
config files). Can somebody tell me what’s wrong. Maybe disk is running
in asynch. mode - then how can I force driver to write data before
exiting (best way will be from application) ?

Thanks in advance
Rafal Bar

Rafal Bar wrote:

config files). Can somebody tell me what’s wrong. Maybe disk is running
in asynch. mode - then how can I force driver to write data before
exiting (best way will be from application) ?

The defaul global asyncrhonous write-back delay is configured via
“Fsys -d” option; you can set this to 0 to force all writes to be
synchronous (but corresponding large performance penalty). Your talk
of corrupt pdm/pwm files reminds me of one (old) version which had
a default as 5 secs (rather than past/future 2 secs) and it manifested
itself this way (so try setting ‘-d2’; and rebuild your boot image!).
Otherwise, you can control the synchronicity on a per-file basis using
O_SYNC or fsync() where appropriate (refer to docs). There is also the
“sync” utility which will initiate writing all data to disk (although
it returns asynchronously after initiated this, doesn’t block for it
to complete).

Thanks. One more question. Is there a method to check if some files are
still in cache ?

Rafal Bar

Rafal Bar wrote:

Thanks. One more question. Is there a method to check if some files are
still in cache ?

No (well, unmounting a filesystem will block until all writes are
flushed, but this is somewhat destructive). You generally have to
assume they’re cached until otherwise known (eg call to fsync()
returns, or O_SYNC and write() returns successfully; recall from
previous post that call to/return from sync() does not make such a
guarantee).