Skip navigation.
Home
The QNX Community Portal

View topic - Fsys 4.25 is less stable than 4.23 Help!

Fsys 4.25 is less stable than 4.23 Help!

Read-only archive of qnx.qnx4 (General QNX4 Discussion Group) at inn.qnx.com

Fsys 4.25 is less stable than 4.23 Help!

Postby Darel Cullen » Tue Sep 26, 2006 1:05 pm

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
 

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Mario Charest » Tue Sep 26, 2006 1:49 pm

"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



Mario Charest
 

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby booBot » Tue Sep 26, 2006 2:03 pm

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.
booBot
Senior Member
 
Posts: 633
Joined: Tue Feb 24, 2004 5:07 pm

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Mario Charest » Tue Sep 26, 2006 4:59 pm

"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.
Mario Charest
 

RE: Re: Fsys 4.25 is less stable than 4.23 Help!

Postby maschoen » Tue Sep 26, 2006 6:59 pm

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.
maschoen
QNX Master
 
Posts: 2644
Joined: Wed Jun 25, 2003 5:18 pm

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Darel Cullen » Wed Sep 27, 2006 8:42 am

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
Darel Cullen
 

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Darel Cullen » Wed Sep 27, 2006 8:45 am

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)
Darel Cullen
 

Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Darel Cullen » Wed Oct 18, 2006 1:48 pm

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?
Darel Cullen
 

RE: Re: Fsys 4.25 is less stable than 4.23 Help!

Postby maschoen » Wed Oct 18, 2006 7:28 pm

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.
maschoen
QNX Master
 
Posts: 2644
Joined: Wed Jun 25, 2003 5:18 pm

Re: Re: Fsys 4.25 is less stable than 4.23 Help!

Postby Darel Cullen » Thu Oct 19, 2006 8:06 am

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 Cullen
 

Re: Re: Fsys 4.25 is less stable than 4.23 Help!

Postby maschoen » Thu Oct 19, 2006 8:02 pm

Darel Cullen wrote: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.
maschoen
QNX Master
 
Posts: 2644
Joined: Wed Jun 25, 2003 5:18 pm


Return to qnx.qnx4

Who is online

Users browsing this forum: No registered users and 2 guests