Product Documentation

Knowledgebase

Previous Topic

Next Topic

FUSE_ERR (22) During Automatic Recovery

Whenever a transaction controlled FairCom DB file is opened, it is assigned a unique "File Id" which is used to reference it in the transaction logs. This number is stored as a 4 byte integer. If large numbers of files are repeatedly opened and closed, the File Ids can be rapidly consumed , leading to a "Pending File ID overflow" message logged in CTSTATUS.FCS. This message is logged every 10,000 file opens. The "File Id" can be reset by shutting down the server cleanly (so no recovery is needed), and removing the transaction logs composed of the L*.FCS and S000*.FCS files.

The FUSE_ERR during recovery is indicating that it needs the FILES setting increased to complete recovery. There is a RECOVER_FILES keyword that controls this specifically.

RECOVER_FILES <number of files | NO>

Newer versions (9.3 and later) only assign "File Id's" when a file is actually updated, and not just opened and read from, which substantially extends the interval before the next overflow.

Previous Topic

Next Topic

Activation Failures (Error 26) on AIX 6

A previously activated server was found to not be activated with a newly provided activation key. The fcactvat utility failed with system error 26 "Text file busy or in use".

AIX 6 can cache shared objects, in this case ctreedbs.so, and fcactvat can then not stamp the binary. An AIX 6 utility, slibclean, is available on that platform that releases the object from the cache allowing successful stamping.

Previous Topic

Next Topic

CPUs Report Different Times on Linux, Causing Unexpectedly Long sleep() Times

On a multi-core system running CentOS Linux, calls to sleep() were observed to take an unexpectedly long time. It is believed the system time reported by the CPUs varies, as was confirmed by this experiment:

The Linux taskset utility can be used to run a process on specified CPUs. The date on each CPU differed:

taskset -c 0 date

taskset -c 1 date

taskset -c 2 date

taskset -c 3 date

Mon Aug 8 11:20:04 CDT 2011

Mon Aug 8 11:20:19 CDT 2011

Mon Aug 8 11:20:16 CDT 2011

Mon Aug 8 11:20:20 CDT 2011

The Hyper-V VM was used in this case and it was found that adding the following boot options resolved the problem, as described here:

http://hardanswers.net/correct-clock-drift-in-centos-hyper-v

divider=10 clocksource=acpi_pm (for 32bit kernel)

TOCIndex