Igor Kovalenko <firstname.lastname@example.org> wrote:
“Robert Krten” <> email@example.com> > wrote in message
news:cji8ci$b28$> firstname.lastname@example.org> …
Nick C. <> email@example.com> > wrote:
I need a QNX system that can be turned on/off without a proper
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
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…
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
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/