Firebird 2.1 Release Notes

Global Improvements in Firebird 2.1
The Firebird developers have no idea why such a bug would remain unfixed almost two years after getting into
the Linux kernel's bug-tracker. Apparently, in Linux, a documented bug evolves into a feature...
Instant Fix for an Older Firebird
Here's a tip if you want to do an instant fix for the problem in an older version of Firebird: use the “sync” option
when mounting any partition with a Firebird database on board. An example of a line in /etc/fstab:
/dev/sda9 /usr/database ext3 noatime,sync 1 2
A. Peshkov
Databases on Raw Devices
File system I/O can degrade performance severely when a database in Forced Writes mode grows rapidly. On
Linux, which lacks the appropriate system calls to grow the database efficiently, performance with Forced Writes
can be as much as three times slower than with asynchronous writes.
When such conditions prevail, performance may be greatly enhanced by bypassing the file system entirely and
restoring the database directly to a raw device. A Firebird database can be recreated on any type of block device.
Moving a Database to a Raw Device
Moving your database to a raw device can be as simple as restoring a backup directly to an unformatted partition
in the local storage system. For example,
gbak -c my.fbk /dev/sda7
will restore your database on the third logical disk in the extended partition of your first SCSI or SATA harddrive
(disk0).
Note
The database does not have a “database name” other than the device name itself. In the example given, the
name of the database is '/dev/sda7'.
Special Issues for nbak/nbackup
The physical backup utility nbackup must be supplied with an explicit file path and name for its difference
file, in order to avoid this file being written into the /dev/ directory. You can achieve this with the following
statement, using isql:
25