The default file system for Neutrino is the same as for
QNX4. It was and still is quite robust. A while ago QSSL
did a modification that caught me and a lot of others by
surprise. This modification can be overwritten by using the
-d option. Basically they extended the amount of time that
dirty cache data buffers could stay in memory. They way
this screwed me up was that I would reflexively exit photon,
and power down. At shutdown a photon config file was
written, but I powered down too quickly for the data to get
to disk. I still respond to poor souls who do this now and
The reason for this change by QSSL was MUCH BETTER PERFORMANCE.
I can live with that. The change can be reversed by putting
a -d0 option on Fsys. I found it easier to just not shut
It is also possible to get much less robust performance out of
the file system by using the -a option to Fsys. This allows
all writes to the disk, including meta-data to be asynchronous.
This is fine for removable media being used for backups, and systems
with RAIDS and UPS’s.
This is all in reference to using the QNX4 file system under QNX4.
I’m still learning about V6, but I doubt that things are much
Previously, Jim Lambert wrote in comp.os.qnx:
I have used Q2 and Q4 for years and am now “messing” around with Neutrino.
Is the Filesystem problem that I hear about equivalent to the filesystem
“problems” these others had? Ie, it isnt as if the filesystem isnt adequate
in most situations, its just not as robust or fast as some others. Is there
something I can read on the FS “problems?” I found an old post from Bill
Flowers (I think that is who it was) that had something about the FS problem
not being as bad as thought, but when I clicked on the link it was dead.
I’m just trying to get a handle on the fs issue to see if it is something
that will obviate using QNX Neutrino or something that just makes it not as
great as it could be.
Mitchell Schoenbrun --------- firstname.lastname@example.org