Hi.
Is there anyway to keep the pdm.cfg file from going bad?
Thanks,
Augie
Augie Henriques <augiehenriques@hotmail.com> wrote:
Hi.
Is there anyway to keep the pdm.cfg file from going bad?
I tend to exit photon, wait a couple seconds, then reboot.
Unfortunately PDM (QNX4, at least) seems to want to re-write
the config on every exit, which means that the file is always
busy and just had data written to it on every exit.
And the default write-behind delay for Fsys is 3 seconds, but if
you do a “shutdown -f” that is a 2 second delay. So, reducing the
write-behind delay for Fsys may also help.
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote in message
news:91tgbs$2n8$6@nntp.qnx.com…
Augie Henriques <> augiehenriques@hotmail.com> > wrote:
Hi.Is there anyway to keep the pdm.cfg file from going bad?
I tend to exit photon, wait a couple seconds, then reboot.
Unfortunately PDM (QNX4, at least) seems to want to re-write
the config on every exit, which means that the file is always
busy and just had data written to it on every exit.And the default write-behind delay for Fsys is 3 seconds, but if
you do a “shutdown -f” that is a 2 second delay. So, reducing the
write-behind delay for Fsys may also help.
As anyone made an effort to fix this problem? This doesn’t assure first
time QNX 4.25 / Photon 1.14 users, specially on a robust real-time OS such
as QNX 4.25.
Augie
-David
QNX Training Services
dagibbs@qnx.com
Previously, Augie Henriques wrote in comp.os.qnx:
As anyone made an effort to fix this problem? This doesn’t assure first
time QNX 4.25 / Photon 1.14 users, specially on a robust real-time OS such
as QNX 4.25.
You also can add a -d parameter to Fsys to decrease the write back
delay, although this will decrease performance. You might also
want to make a copy of the file so that if the problem happens,
you can recover. Lastly, you can do what I do, which is to just
power down while in Photon.
This is not really a bug as much as a big annoyance. I
know, I spent 4 months trying to figure out what this was
before anyone else knew about it. There is nothing that
QSSL, nor anyone else can do to force a system to do
simulataneous writes to a disk. You should note that while
the data has been lost, the file structure is still intact.
I do agree that a small amount of effort could remove this
wart. One possibility would be to only write the file back
if it has changed. Another would be to sync the file
system after the close.
Mitchell Schoenbrun --------- maschoen@pobox.com
Mitchell Schoenbrun <maschoen@pobox.com> wrote in message
news:Voyager.001221115804.7107A@schoenbrun.com…
Previously, Augie Henriques wrote in comp.os.qnx:
As anyone made an effort to fix this problem? This doesn’t assure first
time QNX 4.25 / Photon 1.14 users, specially on a robust real-time OS
such
as QNX 4.25.You also can add a -d parameter to Fsys to decrease the write back
delay, although this will decrease performance. You might also
want to make a copy of the file so that if the problem happens,
you can recover. Lastly, you can do what I do, which is to just
power down while in Photon.This is not really a bug as much as a big annoyance. I
know, I spent 4 months trying to figure out what this was
before anyone else knew about it. There is nothing that
QSSL, nor anyone else can do to force a system to do
simulataneous writes to a disk. You should note that while
the data has been lost, the file structure is still intact.
I think this is a bug. Losing the Photon Desktop Manager is not good.
I do agree that a small amount of effort could remove this
wart. One possibility would be to only write the file back
if it has changed. Another would be to sync the file
system after the close.
Yep. They could also keep a backup file and use that file, in case the
original goes bad. The user should not have to do this, it takes away from
“user friendly”.
Can’t the pdm.cfg file be updated only when something changes? Does it have
to be updated after Photon exits? Why? Why not make Photon wait to go to
the QNX shell until after the file has been updated?
Personally, I don’t like any of the options mentioned so far for fixes. I
would like to see this problem corrected in Photon.
Augie
Mitchell Schoenbrun --------- > maschoen@pobox.com
Augie Henriques wrote:
[bad pdm config files]
Yes, you (and many others) are victims of a “flowery performance
optimisation” (writing blocks to disk is slow, so don’t do it!).
This is fixed in Fsys 4.24O, although I strongly recommend you
upgrade to 4.24V as it also fixes deadlocks in link(), rename(),
and write(), fixes message buffer corruption bugs with stat(),
ramdisk issues, ENOSPC fixes, ensures fsync() always physically
writes inodes, and also bugs with discarded disk writes to
_REMOVABLE media (and more).
This is not really a bug as much as a big annoyance. I
I think this is a bug. Losing the Photon Desktop Manager is not good.
Yes, it is plainly a bug. Delayed-writes of bitmap blocks (as a
performance aid) is simply unacceptable without explicit user
compliance (Fsys -a). Suggestions involving ‘-d’ just move the
timing window of corruption and are a poor substitute for upgrading.
It is a pity that QNX4/NTO filesystem issues receive little informed
official comment and too much unofficial unfounded glory-day rhetoric.
John Garvey <jpg@cisco.com> wrote in message
news:3A4374B1.5BF6EC6D@cisco.com…
Augie Henriques wrote:
[bad pdm config files]
Yes, you (and many others) are victims of a “flowery performance
optimisation” (writing blocks to disk is slow, so don’t do it!).This is fixed in Fsys 4.24O, although I strongly recommend you
upgrade to 4.24V as it also fixes deadlocks in link(), rename(),
and write(), fixes message buffer corruption bugs with stat(),
ramdisk issues, ENOSPC fixes, ensures fsync() always physically
writes inodes, and also bugs with discarded disk writes to
_REMOVABLE media (and more).
Where can I get this version from? Is it on QUICS, web site, QDN?
Thanks
Augie
This is not really a bug as much as a big annoyance. I
I think this is a bug. Losing the Photon Desktop Manager is not good.Yes, it is plainly a bug. Delayed-writes of bitmap blocks (as a
performance aid) is simply unacceptable without explicit user
compliance (Fsys -a). Suggestions involving ‘-d’ just move the
timing window of corruption and are a poor substitute for upgrading.It is a pity that QNX4/NTO filesystem issues receive little informed
official comment and too much unofficial unfounded glory-day rhetoric.