fs-qnx filesystem questions

QNX Newsgroups (Archives) qdn.public.qnxrtp.applications
1

Hi,

I appreciate if somebody could answer following questions related to fs-qnx
filesystem for QNX/Neutrino.

  1. What is the maximum volumn that a partition can support? Is it limited
    to 32 bit or 64bit? How about the maximum file size?

  2. The disk blocks are allocated by extents. Do we specify the initial and
    growth extent size when you create a file? Or is it determined by the
    filesystem. If the latter is the case, how is it determined?

  3. How does it perform in terms of recovering from the system crash? How
    does it compare to UNIX filesystem? How about journalled filesystem?

Thanks in advance.
-chang

2

“Operating System Tech Support” <os@qnx.com> wrote in message
news:9r1kou$kcd$1@nntp.qnx.com…

  1. How does it perform in terms of recovering from the system crash?
    How
    does it compare to UNIX filesystem? How about journalled filesystem?

It depends by what you mean as “recovering from a system crash”. Many of
the journalling filesystems, use journaling to restore/fix their
filesystem
Meta data and FS integrity but it does not do data recovery.

I don’t think that’s quite true. Unixes will lose files being written at the
time of crash, just like QNX will.

The problem is that many of the *NIX like FS’s is that they have very
agressive cache mechanisms to avoid disk access. This is great for
general
use, but if the system goes down, before those caches are flushed and
commited, you data is gone.

Hmm. That’s not really as much ‘aggressive caching’ as well designed buffer
cache system. In most modern Unixes buffer cache and VM are unified and OS
can automatically adjust buffer cache as usage pattern suggests. Granted,
that (unification) may have adverse effect on realtime, but in QNX they are
not only non-unified, but every devb-xxx has its own cache. That does not
help performance at all and does not help reliability as far as I can see.

In short, the QNX FS might not be as fast as some of the journaled FS/*NIX
but it’s very reliable.

It is reliable, but not really so much more reliable than modern UFS
variants to justify such poor piss performance anymore. I spent lot of
efforts trying to get maximum performance of it and results were at best
modest.

Truth is, QNX4 FS was good enough in its days, but by now is simply too damn
old. It does not reflect any of developments in this area of past decade
(which in computer industry means it is relict). Write performance is
especially bad and it also seems to suffer severely from cache saturation
effects. Under some conditions throughput can drop as low as 200kb/sec when
copying a large file within same drive, and that is using DMA mode of EIDE
(!)

It is really sad part of QNX (along with VM) and I suggest you guys stop
using excuses already and do something about it. Claims of ‘leading realtime
OS’ and ‘most advanced architecture’ are starting to look somewhat
ridiculous.

  • igor

P.S. cross-posted to OS group where it belongs

3

Igor Kovalenko <kovalenko@home.com> wrote:

It is reliable, but not really so much more reliable than modern UFS
variants to justify such poor piss performance anymore. I spent lot of

have to agree with you. I had a big pain last weekend, trying to
backup one of my RTP partition (QNX4 77). What I did was to run
“mkisofs” to create a ISO file (~650M) and then move to Windows
to burn a CD of it. Gee, it is damn slow and I had to give up.

efforts trying to get maximum performance of it and results were at best
modest.

Truth is, QNX4 FS was good enough in its days, but by now is simply too damn
old. It does not reflect any of developments in this area of past decade

can’t agree with you here. I don’t think it is QNX4 FS old, it is
probably its implemention, or maybe it is the low level hard disk driver.
Last weekend, after giving up on the backup in RTP. I booted into
Linux, mounted the QNX partition and then “mkisofs”. You can’t
imagine how fast it is. Remember this is the same QNX4 FS, just
the different implmentation. Maybe QSSL can take a peek.

Frank

(which in computer industry means it is relict). Write performance is
especially bad and it also seems to suffer severely from cache saturation
effects. Under some conditions throughput can drop as low as 200kb/sec when
copying a large file within same drive, and that is using DMA mode of EIDE
(!)

It is really sad part of QNX (along with VM) and I suggest you guys stop
using excuses already and do something about it. Claims of ‘leading realtime
OS’ and ‘most advanced architecture’ are starting to look somewhat
ridiculous.

  • igor

P.S. cross-posted to OS group where it belongs

–

My public key can be found at
http://mama.indstate.edu/users/liug/key.txt

4

LiuG wrote:

Igor Kovalenko <> kovalenko@home.com> > wrote:
Truth is, QNX4 FS was good enough in its days, but by now is simply too damn
old. It does not reflect any of developments in this area of past decade

can’t agree with you here. I don’t think it is QNX4 FS old, it is
probably its implemention, or maybe it is the low level hard disk driver.
Last weekend, after giving up on the backup in RTP. I booted into
Linux, mounted the QNX partition and then “mkisofs”. You can’t
imagine how fast it is. Remember this is the same QNX4 FS, just
the different implmentation. Maybe QSSL can take a peek.

When I said QNX4 FS is old, i mean its on-disk layout and algorithms.
They might be good enough for read access if framework is implemented
properly, as your test using Linux suggests, but they are not good at
writing, by today’s standards.

When I said filesystem is sad piece of QNX, I meant filesystem in broad
sense. Large part of Unix kernel actually contributes to filesystem
performance, particularly VFS and VM/buffer cache subsystems. In QNX VM
is either non-existant (non-x86) or separate (and rudimentary) and the
rest is part of ‘filesystem module’ which includes drivers, FS DLLs, CAM
DLLs, block I/O DLL.

As you saw yourself, better FS framework (of Linux) allows for better
performance even using QNX4 FS. You can also see that bad framework (of
QNX) will not allow any good performance even on Linux ext2 filesystem
(try it under QNX). You can also try writing to QNX filesystem under
Linux (if that is supported) and you’ll see it will suck compared to any
modern filesystem.

I hope i made myself clear this time. And this really should be
continued in .os group.

  • igor
5

“Chang Im” <chim@cisco.com> wrote in message
news:9qnlm5$3fg$1@inn.qnx.com…

Hi,

I appreciate if somebody could answer following questions related to
fs-qnx
filesystem for QNX/Neutrino.

This is a question best suited for qdn.public.qnxrtp.os

  1. What is the maximum volumn that a partition can support? Is it
    limited
    to 32 bit or 64bit? How about the maximum file size?

32-bits is the addressing capability - so 2^32 512 byte blocks = 2 TB,
individual files are limited to 2GB on that parition.

  1. The disk blocks are allocated by extents. Do we specify the initial
    and
    growth extent size when you create a file? Or is it determined by the
    filesystem. If the latter is the case, how is it determined?

No, the filesystem has a heuristic that will allocate larger and larger
extends as the file use dictates (to avoid fragmentation). Once the file is
closed, any extra unused extend space will be remarked as available again.

You can specify as a user parameter to implement an even more agressive
extent over-allocation heuristic. (overalloc is the option).

  1. How does it perform in terms of recovering from the system crash? How
    does it compare to UNIX filesystem? How about journalled filesystem?

It depends by what you mean as “recovering from a system crash”. Many of
the journalling filesystems, use journaling to restore/fix their filesystem
Meta data and FS integrity but it does not do data recovery.

The problem is that many of the *NIX like FS’s is that they have very
agressive cache mechanisms to avoid disk access. This is great for general
use, but if the system goes down, before those caches are flushed and
commited, you data is gone.

In short, the QNX FS might not be as fast as some of the journaled FS/*NIX
but it’s very reliable.

-Adam