Fsys 4.25 is less stable than 4.23 Help!

Hi,

We have recently tried to upgrade one of our applications to run under 4.25
(latest patch) instead of 4.23A.
We have noticed that the Filesystem is less stable if there occurs a power
outage during file writing. The Filesystem seems to be able to go ‘out of
sync’ and/or files disappear completely from the system!.

Is there anything we are doing incorrectly?

first we start Fsys. -c 256 -r 512

then we start Fsys.ata with no parameters.

The hardware is normal PC hardware with an ATA harddisk

Proc32 is ver 4.25Q

Slib16 is ver 4.23G

Slib32 is ver 4.24B

Fsys32 is ver 4.24Y

/Darel

“Darel Cullen” <nospam-darelj@gmail.com> wrote in message
news:efb82a$972$1@inn.qnx.com

Hi,

We have recently tried to upgrade one of our applications to run under
4.25 (latest patch) instead of 4.23A.
We have noticed that the Filesystem is less stable if there occurs a power
outage during file writing. The Filesystem seems to be able to go ‘out of
sync’ and/or files disappear completely from the system!.

Is there anything we are doing incorrectly?

first we start Fsys. -c 256 -r 512

256 bytes of cache??? I check the doc and there is no -r option available
for Fsys.

then we start Fsys.ata with no parameters.

Try Fsys.atapi or Fsys.eide. And mount the driver with option -s.

The hardware is normal PC hardware with an ATA harddisk

Proc32 is ver 4.25Q

Slib16 is ver 4.23G

Slib32 is ver 4.24B

Fsys32 is ver 4.24Y

/Darel
\

On Tue, 26 Sep 2006 17:49:49 +0400, Mario Charest postmaster@127.0.0.1
wrote:

I check the doc and there is no -r option available for Fsys.
Really?

“-r ramdisk_size” The size of an optional ramdisk, in units of 1kB. The
minimum size is 4kB. A block special file called /dev/ram is created.

(taken from the paper docs for QNX v4.25)

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:op.tghn0fh4o93ri4@mobile.wst.quantum.ru

On Tue, 26 Sep 2006 17:49:49 +0400, Mario Charest <postmaster@127.0.0.1
wrote:

I check the doc and there is no -r option available for Fsys.
Really?

Sorry my mistake.

“-r ramdisk_size” The size of an optional ramdisk, in units of 1kB. The
minimum size is 4kB. A block special file called /dev/ram is created.

(taken from the paper docs for QNX v4.25)

Tony.

I don’t know what versions were involved, but there was a change to
Fsys to delay disk flushes.
This caused lots of problems at first. One solution was to either
wait a few seconds after the
last activity before powering down. The other was a parameter to Fsys
which shortened the delay.

256 bytes of cache??? I check the doc and there is no -r option available
for Fsys.

Hi, Yes , we thought this was strange and got rid of it too (inhereted very
old software!) so we let the Fsys do its own cache calculations instead.
That improved matters a deal but there is still a problem.

then we start Fsys.ata with no parameters.

Try Fsys.atapi or Fsys.eide. And mount the driver with option -s.

Fsys.atapi seems to be the ‘latest and greatest’ software so yes we should
look into updating to that to see if it helps matters any (from what I read
the performance is alot better too).

Thanks for your help

/Darel

256 bytes of cache??? I check the doc and there is no -r option available
for Fsys.

I think the default is in ‘K’ so it would be 256K of cache… (which is still
too small probably)

Try Fsys.atapi or Fsys.eide. And mount the driver with option -s.

Hi,
We are trying to use Fsys.atapi now for our 4.25 file system but still
seeing serious file corruption if the power is removed during file write. Do
you have a good suggestion for a value to use with the -s option?

If you have a file open for write, and you are writing to it when the
power is pulled, you will amost always end up with a corrupt file.
One way to prevent this is to create the file ahead of time, and then
update the file as you go. You will need some way to figure out how
far into the file you’ve written.
Of course you still run the risk of corruption when you are creating
this file, but at least you do not lose any data.


It is possible to write a file system that does not have this problem,
but it would be very inefficient as it would need to pre-write all
data and meta-data, and then be able to roll back in case of a crash.

Hi Maschoen,

Yes I guess you are right… Although with the earlier QNX file systems we
saw that files would disappear rather than be filled with garbage characters
which is significantly less nerfarious…

“maschoen” <maschoen@pobox-dot-com.no-spam.invalid> wrote in message
news:eh610f$51l$1@inn.qnx.com

If you have a file open for write, and you are writing to it when the
power is pulled, you will amost always end up with a corrupt file.
One way to prevent this is to create the file ahead of time, and then
update the file as you go. You will need some way to figure out how
far into the file you’ve written.
Of course you still run the risk of corruption when you are creating
this file, but at least you do not lose any data.


It is possible to write a file system that does not have this problem,
but it would be very inefficient as it would need to pre-write all
data and meta-data, and then be able to roll back in case of a crash.

It is also possible to do this in the application i guess by the use of
checksums and known-good backups.
If one reads the QNX documentation they claim their filesystems are designed
to be hard to corrupt, I guess thats a subjective statement but from what we
see it is currently quite easy to corrupt the filesystem - A total blackout
is something our systems have to contend with I guess the only way around it
is a UPS and controlled shutdown…

One more thing, We are using 4.25 latest patch but still using the 9.5
Watcom compiler (and headers). This wouldnt make any difference to
filesystem stability would it?

Darel Cullenwrote:
Hi Maschoen,

Yes I guess you are right… Although with the earlier QNX file
systems we
saw that files would disappear rather than be filled with garbage
characters
which is significantly less nerfarious…

I’m not exactly sure what you are refering to when you say files would
disappear. Under QNX 2, if you create a file with zero bytes, and
then close it, it would disappear. This was normal correct behavior
for QNX 2.
Under QNX 4 this changed to be Posix conforming. Zero byte files can
exist. If you mean that when you open a file, and the system
crashes before you write anything to it, I would agree that this is a
relatively good way to handle the corruption, but it is probably a
coincidence that it turned out that way.

If one reads the QNX documentation they claim their filesystems are
designed
to be hard to corrupt, I guess thats a subjective statement but from
what we
see it is currently quite easy to corrupt the filesystem - A total
blackout
is something our systems have to contend with I guess the only way
around it
is a UPS and controlled shutdown…

I think you are reading their statement to mean it is hard to corrupt
a file, which is not what it says. With older Unix systems, which
is probably what this statement is comparing QNX’s file system to, if
you shut down improperly, your file system is corrupt. You cannot
start until the file system has been reconstituted, a fairly long
procedure This is a consequence of the infamous super-block.
QNX’s file system on the other hand will usually only corrupt the
files open for write or append. Even these files can often have
their contents read before you zap them.
Admittedly file file system landscape has changed a lot since this
documentation was written, probably around 1990.


One more thing, We are using 4.25 latest patch but still using the
9.5
Watcom compiler (and headers). This wouldnt make any difference to
filesystem stability would it?

No way that I can see.