I need a QNX system that can be turned on/off without a proper “shutdown”
command. If possible I’d like to use solid state disk as well.
What examples can you guys share where you’ve done something like this.
How can I eliminate file system corruption altogether? Maybe booting from
ROM/CD-ROM?
Thanks
“Nick C.” <qnx@qrts.com> wrote in message news:cjhrag$29k$1@inn.qnx.com…
I need a QNX system that can be turned on/off without a proper “shutdown”
command. If possible I’d like to use solid state disk as well.What examples can you guys share where you’ve done something like this.
How can I eliminate file system corruption altogether? Maybe booting from
ROM/CD-ROM?
The media being used does not matter as much as what you’re doing with it
and how you’re doing it. If you want your system to boot up reliably, you
need to split your filesystem into a read-only part that’s used to boot into
some basic state and writable part that you can afford to lose. The trick is
if you lost the writable part your boot scripts can recreate it on the
fly…
Using flash filesystem may or may not help here. On one hand, it is not
prone to mechanical issues, on the other hand the filesystem itself
(software) is less mature and may exhibit some funky behavior. I would
suggest compact flash as a reasonable approach since it is a flash yet you
can use the standard filesystem…
– igor
Nick C. <qnx@qrts.com> wrote:
I need a QNX system that can be turned on/off without a proper “shutdown”
command. If possible I’d like to use solid state disk as well.What examples can you guys share where you’ve done something like this.
How can I eliminate file system corruption altogether? Maybe booting from
ROM/CD-ROM?
Thanks
What are your requirements for the writable part? As Igor mentions, you
can certainly use the traditional QNX filesystem for the “read-only” part.
If you can make your writable part more like a “journaling” filesystem,
then you should be able to make it a lot more robust. Of course this
involves writing a custom filesystem, or at least porting one…
Cheers,
-RK
–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/
“Robert Krten” <rk@parse.com> wrote in message
news:cji8ci$b28$1@inn.qnx.com…
Nick C. <> qnx@qrts.com> > wrote:
I need a QNX system that can be turned on/off without a proper
“shutdown”
command. If possible I’d like to use solid state disk as well.What examples can you guys share where you’ve done something like this.
How can I eliminate file system corruption altogether? Maybe booting
from
ROM/CD-ROM?
ThanksWhat are your requirements for the writable part? As Igor mentions, you
can certainly use the traditional QNX filesystem for the “read-only” part.If you can make your writable part more like a “journaling” filesystem,
then you should be able to make it a lot more robust. Of course this
involves writing a custom filesystem, or at least porting one…
I don’t think there’s a good reason to do that in the given context. The
first question should be WHAT are you writing. What is the nature of the
data and what is the pattern. Is it fixed-size/variable content or variable
size/variable content? Is the data supposed to be permanent or transient? If
it is transient, is it expendable? If fixed size, how often does content
change?
Basically, if you are dealing with permanent non-expendable type of data,
then doing ungraceful shoutdowns should be out of question no matter what
filesystem is used. Or you just can’t store that data on the system in
question and should stream it out to some remote storage server not subject
to sudden resets. The data important enought to bother recovering should not
be subjected to maltreatment at least by design.
In most other situations you can just ignore the losses and reconstruct the
transient filesystem every time you boot (or when corrupted).
A good design will identify distinct types of data and their writing
patterns and split filesystems into separate volumes and or devices
accordingly. All writing activity would ideally be isolated and routed
through a dedicated software component to allow you to set and change
writing policies on the go. Boot scritps should have capability to fill in
any missing expendable data with reasonable defaults or values obtained
thought network (DHCP can help a lot and not only with IPs). It is much
better to NOT depend on data resiliency whenever possible than to depend on
any kind of data recovery.
– igor
Igor Kovalenko <kovalenko@comcast.net> wrote:
“Robert Krten” <> rk@parse.com> > wrote in message
news:cji8ci$b28$> 1@inn.qnx.com> …
Nick C. <> qnx@qrts.com> > wrote:
I need a QNX system that can be turned on/off without a proper
“shutdown”
command. If possible I’d like to use solid state disk as well.What examples can you guys share where you’ve done something like this.
How can I eliminate file system corruption altogether? Maybe booting
from
ROM/CD-ROM?
ThanksWhat are your requirements for the writable part? As Igor mentions, you
can certainly use the traditional QNX filesystem for the “read-only” part.If you can make your writable part more like a “journaling” filesystem,
then you should be able to make it a lot more robust. Of course this
involves writing a custom filesystem, or at least porting one…I don’t think there’s a good reason to do that in the given context. The
first question should be WHAT are you writing. What is the nature of the
“WHAT are you writing” == “What are your requirements for the writable part” 
data and what is the pattern. Is it fixed-size/variable content or variable
size/variable content? Is the data supposed to be permanent or transient? If
it is transient, is it expendable? If fixed size, how often does content
change?Basically, if you are dealing with permanent non-expendable type of data,
then doing ungraceful shoutdowns should be out of question no matter what
filesystem is used. Or you just can’t store that data on the system in
question and should stream it out to some remote storage server not subject
to sudden resets. The data important enought to bother recovering should not
be subjected to maltreatment at least by design.
And yet, an ungraceful shutdown (“shoutdowns”? Too many meetings? ) is
a fact of life. Certainly, there are ways of dealing with this, either with
a “journaling” type of filesystem or with a primary/backup type of filesystem
where sequence numbers are used and one filesystem is updated and then the other
is updated so that you always have a consistent view of the world – the most
you’ll lose is your last transaction, and even that can at least be detected…
In most other situations you can just ignore the losses and reconstruct the
transient filesystem every time you boot (or when corrupted).A good design will identify distinct types of data and their writing
patterns and split filesystems into separate volumes and or devices
accordingly. All writing activity would ideally be isolated and routed
through a dedicated software component to allow you to set and change
writing policies on the go. Boot scritps should have capability to fill in
any missing expendable data with reasonable defaults or values obtained
thought network (DHCP can help a lot and not only with IPs). It is much
better to NOT depend on data resiliency whenever possible than to depend on
any kind of data recovery.
I think we’re violently agreeing here
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/
Igor Kovalenko wrote:
Nick C. <> qnx@qrts.com> > wrote:
I need a QNX system that can be turned on/off without a proper
“shutdown” command. If possible I’d like to use solid state disk as well.
A good design will identify distinct types of data and their writing
patterns and split filesystems into separate volumes and or devices
accordingly. All writing activity would ideally be isolated and routed
Try and structure your application to avoid certain problematic
situations. For example, extending a file requires multiple writes to a
number of separate on-disk structures (bitmap, inode, xtnt block), and
whilst these are internally ordered to minimise the nature of
corruption, a power fail in the middle of the sequence could result in
blocks marked as used but not or a “busy” file. Pregrow your data/log
files where possible (either at install time or at key checkpoints) and
use some other internal mechanism to recognise logical EOF. Thus, any
dynamic writes are just over-writes, and are not modifying the logical
filesystem structure, hence power-loss is less destructive. Make your
logs rotary (for example, syslogd with its naive O_APPEND concatentation
to syslog will almost always be growing the log and leave it as “busy”;
I replace /var/log/syslog with a rotary-logfile resmgr which helps with
the occasional powercut I have). There are some other hints in the new
“Fine-tuning your Filesystems” chapter of the 6.3 docs (which talk about
the various sync modes, using <=16-char filenames, etc).
Thanks for all the informative replies guys, they are very helpful and
interesting! Lots of good ideas.
Data I need to write is transient and not at all important. What is KEY is
that the QNX system never get stuck in a manual recovery mode (a-la Linux
single user fsck required mode).
Some folks confirmed that as long as there are no open files when the power
is cut there will be no problem. This begs the question - assuming I know
when my processes open files, what other QNX daemons are opening and writing
to files?
syslog etc? qnet? phrelay?
There’s clean way to ensure there’s no surprizes with QNX. When it boots up,
the procnto mounts / read-only. The rest is ENTIRELY up to you. Mount your
hard/flash disk under some unusual location (like /flash). Then run
everything from there. If some stuff really expects certain pathnames (for
example you MUST have /usr/lib/ldqnx.so) then you either create a symlink or
procmgr prefix to individual files. Keep as much as you can read-only and
only have one small writable partition that does not store anything else but
some small config files you may need to edit. And keep a writable RAM
filesystem for /tmp. If you want to, create links from READ-ONLY partition
under /flash to ‘standard’ locations like /bin and /lib. The goal is to have
only few controlled locations where writing is technically possible.
At the point, if some daemons/applications try to write where you don’t
expect, they will fail. You pick them one by one and fix what you have to.
To do that you may need syslog and/or slogger. The syslog writes to location
of your choice (controlled by syslogd.conf as usual). The slogger writes to
an in-memory circular buffer.
I have done a system with configuration like that and it never got stuck
booting when we played with the power switch.
“Nick C.” <qnx@qrts.com> wrote in message news:ckgu7a$m0d$4@inn.qnx.com…
Thanks for all the informative replies guys, they are very helpful and
interesting! Lots of good ideas.Data I need to write is transient and not at all important. What is KEY is
that the QNX system never get stuck in a manual recovery mode (a-la Linux
single user fsck required mode).Some folks confirmed that as long as there are no open files when the
power
is cut there will be no problem. This begs the question - assuming I know
when my processes open files, what other QNX daemons are opening and
writing
to files?syslog etc? qnet? phrelay?
igor
thanks for the tips i will try it
nick