If you have access to the old archives, look at the fsys thread
starting around 6337 - it actually started before that.
Here is one of John’s posts:
From quics!jgarvey Fri Oct 8 18:11:55 1999
Xref: quics quics.experts.fsys:6346
From: firstname.lastname@example.org (John Garvey)
Subject: Re: EMFILE on a lightly loaded system
Organization: QNX Software Systems
References: <FJ42II.email@example.com> <FJ5D8p.35J@qnx.com>
X-Newsreader: TIN [version 1.2 PL2]
Date: Wed, 6 Oct 1999 19:40:47 GMT
Jay Hogg (firstname.lastname@example.org) wrote:
Did anything interesting appear in traceinfo?
If your look towards the end of ~/snapshot.emfile there are a number
of traceinfo entries that didn’t get translated (even using traceinfo.net)
so I would have to say ‘yes’ but I don’t know what they are.
Oct 04 20:22:38 2 00003024 0000F7B1 0004E781 656C6966
Oops, these are “internal heap exhaustion (object=file)”. So you
have enhausted the data heap of Fsys (since it shares its DS with the
drivers it pregrows this at startup to a guesstimate value). What
was fooling me was that this situation will return ENFILE from Fsys,
not the EMFILE you were seeing?!
One of my guys reported Fsys -f 1200 (apparently) fixed the problem
Yes, increasing that parameter (or -i or -C too) bumps the heap guess
I’d say you’ve recently added an extra or a bigger drive to the system,
and the heap guess is now too small. You can increase it with the
“Fsys -H” parameter. The traceinfo message shows the size of
the heap that was guessed (drive-specific, because no drives have yet
been attached) plus what was created taking into account known
(-f, -i, -C, etc). You should add some onto the first number and use
this to -H. I’ve put a format line that you can add into your
“/etc/config/traceinfo” file (in the Fsys section) to format this …
36 internal heap exhaustion (nbytes=%ld/%ld) (object=%s)
“Bill Caroselli @ Q-TPS” wrote:
I remember being a victim of this. We had about 12 SCSI disks with 2
partitions each. We had to supply the -H parameter.
But I don’t think it referred to pure size. I think it referred to number
of block special files (partitions that were mounted).
But that was long ago. Hope this help some but I can’t swear that my memory
is 100% on this one.
“Rob” <> email@example.com> > wrote in message
news:9c1t06$por$> firstname.lastname@example.org> …
A couple of years ago there was a thread in quics concerning very large
drives and (as I recall) Fsys running out of heap space. Someone at QSSL
provided an elaborate calculation for providing a numeric value for the -H
option to Fsys. It was based on sectors, heads etc. At that time we were
trying to get a 70G RAID system working (and did so successfully). The
number that was arrived at was 215040.
I thought I had kept some notes on this, but I can’t seem to find them now
and there doesn’t seem to be anything in the QDN knowledge base or even
option for Fsys documented anywhere.
We’re now trying to get an 18G RAID system working… I suspect the 215040
is just a bit of overkill. We’re using Fsys version 4.24B on our
My questions are…
Is there a newer version of Fsys that doesn’t require the -H option for
If not, can some one please dig up the documentation on how to calculate
“the number” required for -H?
OR is 18G safely under the limit for needing the -H option? FYI… there
actually ~26G of disk on the new system… an 8G boot drive (with 2
partitions (t77 & t78) and an 18G “user” drive (with 1 t77 partition).