On Tuesday, January 15, 2002, at 01:41 AM, ibfa2000 wrote:

> Hi,
>
> (Firebird 1.0.0RC2)
> (Embedded PC 33MHz, Linux SuSe)
>
> We are trying to use Firebird on an embedded PC running an embedded
> Linux. Our first tests indicate that things are going pretty well.
>
> Here a few questions:
>
> Since it is an embedded PC that has no disk but only flash RAM (seen
> by linux as an IDE interface), we are trying to save space. So:
>
> - Is it possible to de-activate interbase.log, or to give it a
> maximum size?

There is no limit that I know of. You can change this in the source. I
think if you stub out the gds__log function (found in
interbase/jrd/gds.c) nothing will get logged. Looking at the function,
if it can't open the log file for appending, it should just skip the
write. So you might try creating a dummy interbase.log file and make
sure all the Firebird processes don't have write permission to the file.

> - I saw that 3 files have been created:
> isc_init1.<hostname>

I _think_ this is just a marker file to say the other files have been
initialized. It may also be used for synchronization control (via file
locks) to control which process gets to initialize the other files.
Either way it shouldn't grow after it is initially created.

> isc_event1.<hostname>

This file is memory mapped into shared memory so the different processes
in Classic can send events to each other. If you are not using events
this shouldn't really grow. SS also uses the event file even though
there is only one server process.

> isc_lock1.<hostname>

This is the database lock table, used by all processes in Classic (I'm
not sure about SS, but I think it also uses the file) to synchronize
access to the database file. It will grow linearly to the number of
simultaneous locks and processes required to access the database. The
original file size of ~100k can hold quite a few locks. I'm not sure
exactly how many locks the file can hold. Others on the list should be
better able to help you there. If you have an upper bound on the
database usage in your product you can test it with that usage level to
see how big the lock file gets.

There is also a utility (gds_lock_print, I think) that dumps the info
from the lock file. I haven't used it lately but it may provide some
insight into how much of the file you are using under heavy load. I
don't know if it comes with the standard FB distribution. You may have
to compile it yourself.

> What are these files for? Are their sire going to grow?

-John