Too many files open

I have QNX4.25D running on 80GB EIDE hard disk.
if I open one file at time, it is opened correctly.
But when I open 2 files, the second immediately
after the first, the open on the second file fails
and error “too many opened files” is produced.
However I have enough resources, problem is
only when there is short time difference between
opening two files.

Can you help me ?

PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25J Sep 09 1999
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24V Feb 18 2000
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.25A Feb 09 2000
//75/bin/Dev Dev16 4.23G Oct 04 1996
//75/bin/Dev.con Dev16.ansi 4.23H Nov 21 1996
//75/bin/Dev.pty Dev16.pty 4.23G Oct 04 1996
//75/bin/Fatfsys Fatfsys 4.26A Mar 27 2000
//75/bin/Pipe Pipe 4.23A Feb 26 1996
//75/bin/Net Net 4.25C Aug 30 1999
//75/bin/Net.rtl Net.rtl 4.25C Feb 17 2000
//75/bin/Mouse Mouse 4.24A Aug 22 1997
//75/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//75//usr/ucb/Socklet Socklet 4.25H Jul 30 1999
//75/
/bin/Photon Photon 1.14B Sep 03 1999
//75/*/bin/phfontpfr Photon Font 1.14H Jan 17 2001

Can you help me ?

As we are facing the same problems with 4.25 patch level E we would like to
have a comment from qnx. I have to use a bigger driver than 20GB because we
are running out of space…

We are getting those errors when recompiling any project (about 20 MB
source)

mfg,
Stefan Scherrer

Stefan Scherrer <Stefan.Scherrer@gmx.net> wrote:

Can you help me ?

As we are facing the same problems with 4.25 patch level E we would like to
have a comment from qnx. I have to use a bigger driver than 20GB because we
are running out of space…

We are getting those errors when recompiling any project (about 20 MB
source)

There was some funkiness with Fsys and large drives – some internal
tables shared common space, and one of the pieces that shared that
space was the bitmap – and on larger drives the bitmap was crowding
out other entries resulting in this error occurring unexpectedly.

I just don’t remember what the option was, though I think it was
an undocumented one.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a9epm4$9h2$1@nntp.qnx.com

Stefan Scherrer <> Stefan.Scherrer@gmx.net> > wrote:
Can you help me ?

As we are facing the same problems with 4.25 patch level E we would like
to
have a comment from qnx. I have to use a bigger driver than 20GB because
we
are running out of space…

We are getting those errors when recompiling any project (about 20 MB
source)

There was some funkiness with Fsys and large drives – some internal
tables shared common space, and one of the pieces that shared that
space was the bitmap – and on larger drives the bitmap was crowding
out other entries resulting in this error occurring unexpectedly.

I just don’t remember what the option was, though I think it was
an undocumented one.

I think it’s option -h in Proc32 or what is Fsys?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

I recall way back when that there was an undocumented -H option to Fsys or
one of its drivers.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a9epm4$9h2$1@nntp.qnx.com

Stefan Scherrer <> Stefan.Scherrer@gmx.net> > wrote:
Can you help me ?

As we are facing the same problems with 4.25 patch level E we would like
to
have a comment from qnx. I have to use a bigger driver than 20GB because
we
are running out of space…

We are getting those errors when recompiling any project (about 20 MB
source)

There was some funkiness with Fsys and large drives – some internal
tables shared common space, and one of the pieces that shared that
space was the bitmap – and on larger drives the bitmap was crowding
out other entries resulting in this error occurring unexpectedly.

I just don’t remember what the option was, though I think it was
an undocumented one.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

I recall way back when that there was an undocumented -H option to Fsys or
one of its drivers.

Fsys does take an undocumented -H option that takes parameters. (At least,
the getopt string in the binary sure looks that way. :slight_smile:

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Hi,

There was some funkiness with Fsys and large drives – some internal
tables shared common space, and one of the pieces that shared that
space was the bitmap – and on larger drives the bitmap was crowding
out other entries resulting in this error occurring unexpectedly.

yes this is exactly what i think some internal stuff of Fsys gets screwed up
on large drives (or is it partitions ?)…

I just don’t remember what the option was, though I think it was
an undocumented one.

You should have the source code so should be not a very big problem to find
the used options…

I dont know how long supplies of Disks smaller than 32 GB (working) will
last. 40 GB will also cause troubles (tested them 10 month ago with no
success and took a 20 GB for qnx which is full by now so I wanted to use 80
GB)

I don’t know if working with lets say 4 partions one small to boot from and
the rest spitted apart would work ??

please check what can be done against this problem because sooner or later
everyone will get this problem…

mfg,
stefan




-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Fsys does take an undocumented -H option that takes parameters. (At
least,
the getopt string in the binary sure looks that way. > :slight_smile:

I will check this one tomorrow.

mfg,
Stefan Scherrer

David Gibbs <dagibbs@qnx.com> wrote:

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I recall way back when that there was an undocumented -H option to Fsys or
one of its drivers.

Fsys does take an undocumented -H option that takes parameters. (At least,
the getopt string in the binary sure looks that way. > :slight_smile:

Can you specify parameter of -H options without :slight_smile: ?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

OK, here’s from the archives. Seems to me this comes up often enough
someone should add this this to the qdn knowledgebase:

From quics!jshogg Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6349
Newsgroups: quics.experts.fsys
Path: quics!jshogg
From: jshogg@qnx.com (Jay Hogg)
Subject: Re: EMFILE on a lightly loaded system
Organization: Gateway Technologies
Message-ID: <FJ7CJv.oF4@qnx.com>
References: <FJ42II.72z@qnx.com> <FJ5D8p.35J@qnx.com>
<7tfji5$f2l$1@gateway.qnx.com> <FJ6pun.6tK@qnx.com> <FJ75Bz.Bu4@qnx.com>
<FJ77DD.8En@qnx.com> <FJ78Ju.Itp@qnx.com>
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Wed, 6 Oct 1999 22:16:43 GMT

I must be missing something here:

It guessed 63k as a starting point…
It grew to 320k then ran out of heap…
So I should bump the initial guess to ~84k
And it can now grow to ???

A funny thing here is some systems run just fine and others
have this problem on a regular basis.

Jay


John Garvey (jgarvey@qnx.com) wrote:

Jay Hogg (> jshogg@qnx.com> ) wrote:
Thank you John!

Sorry for not catching it sooner, the EMFILE/ENFILE fooled me (and
still has), but I should have looked more thoroughly at your logs.
I have been pretty swamped recently though > :frowning:

How about a hint to what it should be since ‘-H’ isn’t documented
and I don’t know what is in it to calculate it?
(ps, fsysinfo doesn’t show it > :slight_smile:

That is why I put the internal guess into the trace message; from
yours it is 63k ------------------v
(e l i f )
Oct 04 20:22:38 2 00003024 0000F7B1 0004E781 656C6966

and grows to 320k --------------------------^
once known space for files/inodes/names/etc has been added. Problem
is the low initial guess steals off the known values for bitmap
tables, and you run out of files/inodes/etc instead.

So, for 28Gig of writable disk, I think you’ll need an extra 20k, so
try “-H86016” (it doesn’t perform nice parsing).

If it still happens (now you know what the traceinfo message is), you
can up it later (or if memory is readily available, up it some more
right now > :slight_smile:

[BTW, this is not a particularly nice area of Fsys/Fsys.* at all > :frowning:
There are some games I could play with the GDT/LDT, but this has its
downsides as well. I have revised the guesses a couple of times, but
it looks like it may be time to up it again.]

From quics!jgarvey Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6350
Newsgroups: quics.experts.fsys
Path: quics!jgarvey
From: jgarvey@qnx.com (John Garvey)
Subject: Re: EMFILE on a lightly loaded system
Organization: QNX Software Systems
Message-ID: <FJ8u84.qw@qnx.com>
References: <FJ42II.72z@qnx.com> <FJ5D8p.35J@qnx.com>
<7tfji5$f2l$1@gateway.qnx.com> <FJ6pun.6tK@qnx.com> <FJ75Bz.Bu4@qnx.com>
<FJ77DD.8En@qnx.com> <FJ78Ju.Itp@qnx.com> <FJ7CJv.oF4@qnx.com>
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Thu, 7 Oct 1999 17:36:05 GMT

Jay Hogg (jshogg@qnx.com) wrote:

I must be missing something here:
It guessed 63k as a starting point…
It grew to 320k then ran out of heap…
So I should bump the initial guess to ~84k
And it can now grow to ???

It cannot grow, that is the problem. It must be pre-grown to a
size large enough to hold the expected number of malloc()s.

So: ‘pregrow_heap’ = ‘known_requirements’ + ‘unknown_requirements’.

‘known_requirements’ are simple to calculate: the sum of ‘-f’, ‘-i’,
‘-C’, etc tables. In your case this came to (320-63)k = 257k.

‘unknown_requirements’ is the problem; each disk/device/partition
needs some memory (will depend on the number of disks), and the
“.bitmap” caches too (depends on size of those disks). This is
where the guess factor comes in - in your case it was 63k. It
is this value that you can override with ‘-H’; the amount of
‘known_requirements’ is always added onto this.

However, since it is all just heap, an incorrect drive guess will
just steal away from the known requirements (which aren’t actually
allocated until needed, hence all the fields in “fsysinfo”) and
give you your problems later on. I guess I could track the delta
between the guess and the actual as you mount/unmount, and log a
message when this number goes negative … may be useful …

Anyway, with my suggestion, heap = 257k (known) + 84k (-H guess) = 341k.
Allocated up front, no growing, fullstop.

From quics!jgarvey Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6353
Newsgroups: quics.experts.fsys
Path: quics!jgarvey
From: jgarvey@qnx.com (John Garvey)
Subject: Re: EMFILE on a lightly loaded system
Organization: QNX Software Systems
Message-ID: <FJAEGK.FLL@qnx.com>
References: <FJ42II.72z@qnx.com> <FJ5D8p.35J@qnx.com>
<7tfji5$f2l$1@gateway.qnx.com> <FJ6pun.6tK@qnx.com> <FJ75Bz.Bu4@qnx.com>
<FJ77DD.8En@qnx.com> <FJ78Ju.Itp@qnx.com> <FJ7CJv.oF4@qnx.com>
<FJ8u84.qw@qnx.com> <FJ8yCA.560@qnx.com> <FJ94vF.8yF@qnx.com>
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Fri, 8 Oct 1999 13:50:45 GMT

Rob Hem (rhem@qnx.com) wrote:

I think we’ve got a similar problem…

Did you get those messages in the tracelog?

Two hard drives:
hd0 - 4 G w/ 2 partitions
hd1 - 70 G w/ 1 partition
Any recomendations for the -H option?

Big disk: try “-H215040”.



andy@microstep-mis.com wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I recall way back when that there was an undocumented -H option to Fsys or
one of its drivers.

Fsys does take an undocumented -H option that takes parameters. (At least,
the getopt string in the binary sure looks that way. > :slight_smile:

Can you specify parameter of -H options without > :slight_smile: > ?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Richard Kramer <rrkramer@kramer-smilko.com> wrote:

OK, here’s from the archives. Seems to me this comes up often enough
someone should add this this to the qdn knowledgebase:

Thanks for tracking this down – this was one I knew I’d seen posted,
but didn’t remember when, or have the time to track down. I was hoping
someone would have it & post it.

-David

From quics!jshogg Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6349
Newsgroups: quics.experts.fsys
Path: quics!jshogg
From: > jshogg@qnx.com > (Jay Hogg)
Subject: Re: EMFILE on a lightly loaded system
Organization: Gateway Technologies
Message-ID: <> FJ7CJv.oF4@qnx.com
References: <> FJ42II.72z@qnx.com> > <> FJ5D8p.35J@qnx.com
7tfji5$f2l$> 1@gateway.qnx.com> > <> FJ6pun.6tK@qnx.com> > <> FJ75Bz.Bu4@qnx.com
FJ77DD.8En@qnx.com> > <> FJ78Ju.Itp@qnx.com
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Wed, 6 Oct 1999 22:16:43 GMT

I must be missing something here:

It guessed 63k as a starting point…
It grew to 320k then ran out of heap…
So I should bump the initial guess to ~84k
And it can now grow to ???

A funny thing here is some systems run just fine and others
have this problem on a regular basis.

Jay



John Garvey (> jgarvey@qnx.com> ) wrote:
Jay Hogg (> jshogg@qnx.com> ) wrote:
Thank you John!

Sorry for not catching it sooner, the EMFILE/ENFILE fooled me (and
still has), but I should have looked more thoroughly at your logs.
I have been pretty swamped recently though > :frowning:

How about a hint to what it should be since ‘-H’ isn’t documented
and I don’t know what is in it to calculate it?
(ps, fsysinfo doesn’t show it > :slight_smile:

That is why I put the internal guess into the trace message; from
yours it is 63k ------------------v
(e l i f )
Oct 04 20:22:38 2 00003024 0000F7B1 0004E781 656C6966

and grows to 320k --------------------------^
once known space for files/inodes/names/etc has been added. Problem
is the low initial guess steals off the known values for bitmap
tables, and you run out of files/inodes/etc instead.

So, for 28Gig of writable disk, I think you’ll need an extra 20k, so
try “-H86016” (it doesn’t perform nice parsing).

If it still happens (now you know what the traceinfo message is), you
can up it later (or if memory is readily available, up it some more
right now > :slight_smile:

[BTW, this is not a particularly nice area of Fsys/Fsys.* at all > :frowning:
There are some games I could play with the GDT/LDT, but this has its
downsides as well. I have revised the guesses a couple of times, but
it looks like it may be time to up it again.]

From quics!jgarvey Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6350
Newsgroups: quics.experts.fsys
Path: quics!jgarvey
From: > jgarvey@qnx.com > (John Garvey)
Subject: Re: EMFILE on a lightly loaded system
Organization: QNX Software Systems
Message-ID: <> FJ8u84.qw@qnx.com
References: <> FJ42II.72z@qnx.com> > <> FJ5D8p.35J@qnx.com
7tfji5$f2l$> 1@gateway.qnx.com> > <> FJ6pun.6tK@qnx.com> > <> FJ75Bz.Bu4@qnx.com
FJ77DD.8En@qnx.com> > <> FJ78Ju.Itp@qnx.com> > <> FJ7CJv.oF4@qnx.com
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Thu, 7 Oct 1999 17:36:05 GMT

Jay Hogg (> jshogg@qnx.com> ) wrote:
I must be missing something here:
It guessed 63k as a starting point…
It grew to 320k then ran out of heap…
So I should bump the initial guess to ~84k
And it can now grow to ???

It cannot grow, that is the problem. It must be pre-grown to a
size large enough to hold the expected number of malloc()s.

So: ‘pregrow_heap’ = ‘known_requirements’ + ‘unknown_requirements’.

‘known_requirements’ are simple to calculate: the sum of ‘-f’, ‘-i’,
‘-C’, etc tables. In your case this came to (320-63)k = 257k.

‘unknown_requirements’ is the problem; each disk/device/partition
needs some memory (will depend on the number of disks), and the
“.bitmap” caches too (depends on size of those disks). This is
where the guess factor comes in - in your case it was 63k. It
is this value that you can override with ‘-H’; the amount of
‘known_requirements’ is always added onto this.

However, since it is all just heap, an incorrect drive guess will
just steal away from the known requirements (which aren’t actually
allocated until needed, hence all the fields in “fsysinfo”) and
give you your problems later on. I guess I could track the delta
between the guess and the actual as you mount/unmount, and log a
message when this number goes negative … may be useful …

Anyway, with my suggestion, heap = 257k (known) + 84k (-H guess) = 341k.
Allocated up front, no growing, fullstop.

From quics!jgarvey Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6353
Newsgroups: quics.experts.fsys
Path: quics!jgarvey
From: > jgarvey@qnx.com > (John Garvey)
Subject: Re: EMFILE on a lightly loaded system
Organization: QNX Software Systems
Message-ID: <> FJAEGK.FLL@qnx.com
References: <> FJ42II.72z@qnx.com> > <> FJ5D8p.35J@qnx.com
7tfji5$f2l$> 1@gateway.qnx.com> > <> FJ6pun.6tK@qnx.com> > <> FJ75Bz.Bu4@qnx.com
FJ77DD.8En@qnx.com> > <> FJ78Ju.Itp@qnx.com> > <> FJ7CJv.oF4@qnx.com
FJ8u84.qw@qnx.com> > <> FJ8yCA.560@qnx.com> > <> FJ94vF.8yF@qnx.com
Distribution: quics
X-Newsreader: TIN [version 1.2 PL2]
Date: Fri, 8 Oct 1999 13:50:45 GMT

Rob Hem (> rhem@qnx.com> ) wrote:
I think we’ve got a similar problem…

Did you get those messages in the tracelog?

Two hard drives:
hd0 - 4 G w/ 2 partitions
hd1 - 70 G w/ 1 partition
Any recomendations for the -H option?

Big disk: try “-H215040”.



andy@microstep-mis.com > wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I recall way back when that there was an undocumented -H option to Fsys or
one of its drivers.

Fsys does take an undocumented -H option that takes parameters. (At least,
the getopt string in the binary sure looks that way. > :slight_smile:

Can you specify parameter of -H options without > :slight_smile: > ?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.


QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

andy@microstep-mis.com wrote:

I have QNX4.25D running on 80GB EIDE hard disk.
if I open one file at time, it is opened correctly.
But when I open 2 files, the second immediately
after the first, the open on the second file fails
and error “too many opened files” is produced.
However I have enough resources, problem is
only when there is short time difference between
opening two files.

O.K. now I have found that if I add -H200000 as
parameter of Fsys, the system is running correctly
also on 60GB HDD. Can I be sure now that it will run
correctly also after year course ?

Andy

This isn’t an official answer… but those 70GB HDD mentioned in the archive
footage Richard dug up (with -H 215040) have been running swimmingly for 3+
years now :wink:

Rob (Hem)

<andy@microstep-mis.com> wrote in message
news:aa12pe$rld$1@charon.microstep-mis.sk

andy@microstep-mis.com > wrote:
I have QNX4.25D running on 80GB EIDE hard disk.
if I open one file at time, it is opened correctly.
But when I open 2 files, the second immediately
after the first, the open on the second file fails
and error “too many opened files” is produced.
However I have enough resources, problem is
only when there is short time difference between
opening two files.

O.K. now I have found that if I add -H200000 as
parameter of Fsys, the system is running correctly
also on 60GB HDD. Can I be sure now that it will run
correctly also after year course ?

Andy

Stefan Scherrer <Stefan.Scherrer@gmx.net> wrote:

please check what can be done against this problem because sooner or later
everyone will get this problem…

To restate, the problem is one of chicken-and-egg. The heap size of Fsys
must be pregrown before any disk driver can attach (since they map in the
buffer cache which locks the DS size), but some items allocated on the
heap (bitmap caches) involve knowing the size of the disk (unknown until
the disk driver attaches). So, a guess is employed, using the size of
the cache (typically a percentage of system memory) to guess at what size
disks you may attach; the current guess allows for about 2-4GB. I am
reluctant to change this for historical and embedded installation
considerations. You can override via the -H option (each 1GB of
mounted writable filesystem space requires 14kB of heap), but you need
to also factor in heap space required by other caches, as per the quoted
thread (this amount is logged in the traceinfo).

For the next QNX4 release I will do the following: marginally increase
the default heap size (allow 3-6GB disk); extend the ‘-H’ processing to
allow the syntax “-HdiskXX” to allow room for an XX GB disk (eg “-Hdisk60”)
in addition to other internal heap requirements (which would normally have
to be manually accounted for with ‘-HXXXX’); and put the ‘-H’ into the
usage message. This will still require user intervention on very large
disks, as I don’t want to dramatically increase the default for existing
systems, but it should now be a very simple/non-black-magic process …

John Garvey <jgarvey@qnx.com> wrote:

Stefan Scherrer <> Stefan.Scherrer@gmx.net> > wrote:
please check what can be done against this problem because sooner or later
everyone will get this problem…

To restate, the problem is one of chicken-and-egg. The heap size of Fsys
must be pregrown before any disk driver can attach (since they map in the
buffer cache which locks the DS size), but some items allocated on the
heap (bitmap caches) involve knowing the size of the disk (unknown until
the disk driver attaches). So, a guess is employed, using the size of
the cache (typically a percentage of system memory) to guess at what size
disks you may attach; the current guess allows for about 2-4GB. I am
reluctant to change this for historical and embedded installation
considerations. You can override via the -H option (each 1GB of
mounted writable filesystem space requires 14kB of heap), but you need
to also factor in heap space required by other caches, as per the quoted

sorry, how can I find the factor exactly ?

thread (this amount is logged in the traceinfo).

For the next QNX4 release I will do the following: marginally increase
the default heap size (allow 3-6GB disk); extend the ‘-H’ processing to
allow the syntax “-HdiskXX” to allow room for an XX GB disk (eg “-Hdisk60”)
in addition to other internal heap requirements (which would normally have
to be manually accounted for with ‘-HXXXX’); and put the ‘-H’ into the
usage message. This will still require user intervention on very large
disks, as I don’t want to dramatically increase the default for existing
systems, but it should now be a very simple/non-black-magic process …

That’s fine, it will be appreciated.

Andy

John Garvey <jgarvey@qnx.com> wrote:

For the next QNX4 release I will do the following: marginally increase
the default heap size (allow 3-6GB disk); extend the ‘-H’ processing to
allow the syntax “-HdiskXX” to allow room for an XX GB disk (eg “-Hdisk60”)
in addition to other internal heap requirements (which would normally have
to be manually accounted for with ‘-HXXXX’); and put the ‘-H’ into the
usage message. This will still require user intervention on very large
disks, as I don’t want to dramatically increase the default for existing
systems, but it should now be a very simple/non-black-magic process …

One additional question:
Can I run Fsys -Hdisk100 on 40GB disk ?
i.e. is the parameter maximum size or it has to fit reality ?

andy@microstep-mis.com wrote:

considerations. You can override via the -H option (each 1GB of
mounted writable filesystem space requires 14kB of heap), but you need
to also factor in heap space required by other caches, as per the quoted
sorry, how can I find the factor exactly ?

Well, that was exactly my point, you can’t, hence the extension to ‘-H’.
An approximation would be to run the system without this and get the
“too many files” error, and then look in the traceinfo log for the 3/36
error, and the difference between the two numbers is the non-disk-related
heap requirements, and add that number to the 14k/1G disk requirement.

John Garvey <jgarvey@qnx.com> wrote:

andy@microstep-mis.com > wrote:
considerations. You can override via the -H option (each 1GB of
mounted writable filesystem space requires 14kB of heap), but you need
to also factor in heap space required by other caches, as per the quoted
sorry, how can I find the factor exactly ?

Well, that was exactly my point, you can’t, hence the extension to ‘-H’.
An approximation would be to run the system without this and get the
“too many files” error, and then look in the traceinfo log for the 3/36
error, and the difference between the two numbers is the non-disk-related
heap requirements, and add that number to the 14k/1G disk requirement.

O.K. Now it is clear. I take for granted that I can add also more.
Thanks, Andy