QNX Fsys speed; more cache or less?

QNX Newsgroups (Archives) qdn.public.qnx4
1

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

How did this happen? I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:

257040 Jan 21 10:09 /mount/eide0/t78/.bitmap
24890710 Jan 21 10:09 /mount/eide0/t79/.bitmap
4606639 Jan 21 10:09 /mount/eide0/t80/.bitmap
257033 Jan 22 14:17 /mount/eide1/t77/.bitmap
257040 Jan 22 14:17 /mount/eide1/t78/.bitmap
29497349 Jan 22 14:17 /mount/eide1/t79/.bitmap

This is on a 733MHz P3 class of processor…

My second question: are there any other parameters that will
radically affect the speed? The only command line options I have
to Fsys are to increase the number of OCBs (as per the previous thread
about “too many open files in system”).

Thanks,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

2

“Robert Krten” <nospam91@parse.com> wrote in message
news:a2p2t5$j2g$1@inn.qnx.com…

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

6k per sec, are you kidding?

How did this happen?

I wonder if the size of the .bitmap file is killing everything

I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

Longer search time in the .bitmap file for empty block???

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:

On my machine I used a cache of 128M with -d120 and -a.

257040 Jan 21 10:09 /mount/eide0/t78/.bitmap
24890710 Jan 21 10:09 /mount/eide0/t79/.bitmap
4606639 Jan 21 10:09 /mount/eide0/t80/.bitmap
257033 Jan 22 14:17 /mount/eide1/t77/.bitmap
257040 Jan 22 14:17 /mount/eide1/t78/.bitmap
29497349 Jan 22 14:17 /mount/eide1/t79/.bitmap

This is on a 733MHz P3 class of processor…

My second question: are there any other parameters that will
radically affect the speed? The only command line options I have
to Fsys are to increase the number of OCBs (as per the previous thread
about “too many open files in system”).

Thanks,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

3

Mario Charest <goto@nothingness.com> wrote:

“Robert Krten” <> nospam91@parse.com> > wrote in message
news:a2p2t5$j2g$> 1@inn.qnx.com> …
I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

6k per sec, are you kidding?

Nope. 6kbytes/second. :frowning:

How did this happen?

I wonder if the size of the .bitmap file is killing everything

That’s what I’m thinking – I just need to know from QSSL if the .bitmap
is given priority in the cache or not. If it is, then nothing else will
get the cache; if it isn’t, it has to be searched on disk every time.

I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

Longer search time in the .bitmap file for empty block???

You’d think Fsys would keep a “high water mark” of where the next free
run of .bitmap entries start… I’m only filling the disk – there is
no other activity taking place – I’m not deleting anything, just filling.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:

On my machine I used a cache of 128M with -d120 and -a.

I don’t want to sacrifice reliability too much – although now that I
have that machine on a UPS I guess it would be ok to up the asynch and
write-behind stuf…

I’ll go and buy some more RAM. That poor machine only has 128M :-0

Cheers,
-RK

257040 Jan 21 10:09 /mount/eide0/t78/.bitmap
24890710 Jan 21 10:09 /mount/eide0/t79/.bitmap
4606639 Jan 21 10:09 /mount/eide0/t80/.bitmap
257033 Jan 22 14:17 /mount/eide1/t77/.bitmap
257040 Jan 22 14:17 /mount/eide1/t78/.bitmap
29497349 Jan 22 14:17 /mount/eide1/t79/.bitmap

This is on a 733MHz P3 class of processor…

My second question: are there any other parameters that will
radically affect the speed? The only command line options I have
to Fsys are to increase the number of OCBs (as per the previous thread
about “too many open files in system”).

Thanks,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

4

On my machine I used a cache of 128M with -d120 and -a.

I don’t want to sacrifice reliability too much – although now that I
have that machine on a UPS I guess it would be ok to up the asynch and
write-behind stuf…

My only problem is when I code ISR and I get the machine to crash.
For these type of program I put a “sync” in the makefile. I’ve been
doing that for years and I’ve lost a single file (got a UPS as well)

5

Robert Krten wrote:

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

How did this happen? I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:

Are you getting directory fragmentation? As you fill up the directory, it
grows, thus fragments? Just a thought…

Rick…

Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479

6

Rick Duff <rick@astranetwork.com> wrote:

Robert Krten wrote:

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

How did this happen? I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:


Are you getting directory fragmentation? As you fill up the directory, it
grows, thus fragments? Just a thought…

It’s possible, but the directory in question had 1k entries in it (a little
on the high side, granted) with the files being only 2k in size…

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

7

That’s what I’m thinking – I just need to know from QSSL if the .bitmap
is given priority in the cache or not. If it is, then nothing else will
get the cache; if it isn’t, it has to be searched on disk every time.

Your bitmap should be about 12Meg. This is a lot more than you would
want to hold in memory at one time, but unless QNX4 uses a, bitmap
must all fit in memory at one time, which I doubt, or a start at the
begining of bitmap search, I also doubt, then something else is going
wrong.

Have you tried a smaller cache?

Generally a single threaded backup should be fairly efficient.

You’d think Fsys would keep a “high water mark” of where the next free
run of .bitmap entries start… I’m only filling the disk – there is
no other activity taking place – I’m not deleting anything, just filling.

Of course it must have some kind of reasonable strategy.

Mitchell Schoenbrun --------- maschoen@pobox.com

8

Rick is on the right path to what I think your problem is but there
are a lot of other factors.

Factors

  • How many files in a directory
  • How long are the filenames
  • How many total files on the disk (54gig is a lot of 2k files!)

Look at:

  1. dinit -i - undocumented, preallocates inodes so it doesn’t
    fragment.
    ls -xh /.inodes will tell you how many fragments.

  2. mkdir -s - documented, keeps directories from fragmenting.

Also look at sysmon - if Fsys is running extremely high then it looking
for where to put it otherwise it may be hardware related.

Jay

“Robert Krten” <nospam91@parse.com> wrote in message
news:a2q2iv$c70$1@inn.qnx.com…

Rick Duff <> rick@astranetwork.com> > wrote:
Robert Krten wrote:

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

How did this happen? I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:


Are you getting directory fragmentation? As you fill up the directory,
it
grows, thus fragments? Just a thought…

It’s possible, but the directory in question had 1k entries in it (a
little
on the high side, granted) with the files being only 2k in size…

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

9

Jay Hogg <Jay.Hogg@t-netix.com.r-e-m-o-v-e> wrote:

Rick is on the right path to what I think your problem is but there
are a lot of other factors.

Factors

  • How many files in a directory

It depends – in the specific case, there were 1k files per directory.
This is the backup of the entire disk – I’m making a mirror.

  • How long are the filenames

Most of them are short – 5 characters.

  • How many total files on the disk (54gig is a lot of 2k files!)

A lot of the files are small (source code), a lot of them are big
(MP3s), some are medium :slight_smile:

Here’s the output of chkfsys:
Directories Files Extents Blocks
Available 235978785/disk
Totals 8876/disk 212051/disk 221532/disk 111890309/disk
Maximums 2095/dir 121/file 1331200/file
Averages 23/dir 1/file 527/file

Look at:

  1. dinit -i - undocumented, preallocates inodes so it doesn’t
    fragment.
    ls -xh /.inodes will tell you how many fragments.

I’ll look into this…

  1. mkdir -s - documented, keeps directories from fragmenting.

Can’t do this – the backup script uses “pax” to create the directories…

Also look at sysmon - if Fsys is running extremely high then it looking
for where to put it otherwise it may be hardware related.

Fsys burns 100% cpu during this time…

Cheers,
-RK

Jay

“Robert Krten” <> nospam91@parse.com> > wrote in message
news:a2q2iv$c70$> 1@inn.qnx.com> …
Rick Duff <> rick@astranetwork.com> > wrote:
Robert Krten wrote:

I’m looking for ways to improve Fsys’s speed.

Currently, I’m doing to about 3 files per second on a copy – with
the files being about 2k in size. (That’s right – 6kbytes/second).

How did this happen? I copied 54G of data from one drive to another,
with the second drive being the mirror drive. The copy got slower
and slower as the second (117G partition) filled.

My question: do I want a larger or smaller Fsys cache? I currently
have it set to 64M. Just looking at the .bitmap files on the
various mounted disks comes to:


Are you getting directory fragmentation? As you fill up the directory,
it
grows, thus fragments? Just a thought…

It’s possible, but the directory in question had 1k entries in it (a
little
on the high side, granted) with the files being only 2k in size…

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.