Sure, please send me a better version at
Sure, please send me it at
No, libjf is a tool can be used to add application and/or system transactionality to your file based applications: it does not matter how your files are used (text, binary, search tree, heap, etc...). An interesting feature is the "transactional read" feature you can use with "R" and "R+" open modes: you can start reading from the point you leaved at previous execution without writing this information in some different place.
No, libjf API offers application level recovery and is independent from specific filesystem/operating system. The effort is to develop only "ANSI C" code, but some exceptions are necessary to avoid bugged or foolish code.
Alberto Bertogli noticed me he developed libjio. "Libjf" and "libjio" are distinct original implementations that solve slightly different problems in the same class: please feed-back me your opinion about "libjf vs. libjio".
I was interested in developing a search technology to manage impressive number of keys, from 10^12 up, with search time and insert time bounded by O(K) where K is the length of the key you are searching/inserting. After some early drafts I realized there's no usage for a huge index if recovery is not guaranteed: you can not insert again 10^12 keys because an application/system crash happened while updating the index and something "gone wrong". A journaling technology was necessary. Developing and improving libjf is a hard task so I don't think I'll be able to develop "tera index" technology too.
It's a special file handled by libjf library and used to store transactional data related to one or more journaled files.
It's a normal file created and managed by libjf: using libjf API you can perform ACID transactions on one or more journaled files as you are used with relational databases. A journaled file can be read with any program like cat, less, etc..., but can be written only using libjf API. Writing a journaled file with different tools breaks recovery properties and the file may be damaged when journal file is opened.
It's a tuple (operating system, libc, C compiler) with these properties:
libjf compiles without warning
stress_test.sh executes without errors.
No. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
Please be sure the new environment complies with these properties:
libjf compiles without warnings
stress_test.sh executes without errors.
package_version: first 3 numbers, 1.2.3
library_version: following 3 number, 4.2.1
date: execute command
description: take a look to original operating system package (CDs, DVDs, etc...)
config_guess: execute command
libc_version: on GNU/Linux rpm-based systems, the command is
rpm -qf /lib/libc.so.6on different operating systems you should use the specific packaging tool ("smit", "sam", "*pkg*", ...)
cc_version: many C compiler accepts -v option to retrieve the version:
cc -vsome C compilers may need something else...
<email@example.com>your fresh tested_arch_record.xml
"Recovery pending" means: "application and/or system crashed before a valid synchronization point and some operations must be performed in order to recover journaled files". "Recovery pending" is a common status in a transactional system.
"Damaged journal" means: "the journal contains at least a record that's not well formed". Recovery can be performed only truncating the journal at last valid record. If damage appears in the middle of the journal - not at tail position - the journal itself is compromised and recovery is not suggested. "Damaged journal" must not be common status in a transactional system.
A native porting is not yet available, but cygwin emulation has been successfully used to compile and test libjf. A native porting will be done, but there's no a release date for this milestone.
libjf has to make a lot of work to supply transactional integrity so the comparison is not a 1:1 race. Take a look to Section 3.3 to read more about libjf benchmarking.