Igor Kovalenko <> email@example.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
I hope i made myself clear this time. And this really should be
continued in .os group.