3. System

You can use utility jf_create to create a new journal file; journaled files may be added using utility jf_join.

You can use utility jf_join where "join" means "a new standard file joins the group of files journaled using a specific journal file".

You can use utility jf_leave where "leave" means "a journaled file leaves its journal and become a standard file".

No, renaming the file breaks the link between journal file and journaled files. To rename a journaled file, use utility jf_rename.

If your rename (man 2 rename) implementation supports move across filesystems yes, otherwise no. GNU/Linux 2.6.x and glibc 2.3.3 do not support this type of operation ( EXDEV error is returned).

You can use utility jf_recover specifically designed for this purpose. This is a quite flexible utility can be used:

• to check if a journal needs recovery

• to create an XML report with the operations would be performed if a recovery phase was performed

• to perform a recovery phase.

Use utility jf_recover with -t flag:

jf_recover -j <my journal name> -t
	  

• 0: journal needs recovery

• 1: journal is damaged

• 2: error

• 3: journal is not in "recovery pending" status.

Use utility "jf_recover" and check exit code is 0. Example:

jf_recover -j <my journal name>
	  

Use utility jf_recover with -t and -f flags:

jf_recover -j <my journal name> -t
	  

jf_recover -j <my journal name> -t -f
	  

Use utility jf_recover specifying -f ("force") flag and check exit code is 0. Example:

jf_recover -j <my journal name> -f
	  

Use utility jf_recover with options -t ("test") and -d ("dump"). Example:

jf_recover -j <my journal name> -t -dh
	  

Use utility jf_recover with option -d ("dump"). Example:

jf_recover -j <my journal name> -dh
	  

Journal maximum size is determined at creation time:

• the program can specify it setting file_size field of struct jf_journal_file_opts_s

• if the program does not specify it, the value of environment var JF_JOURNAL_SIZE is used

• if environment var JF_JOURNAL_SIZE is not set, the default value (see hard wired constant JF_JOURNAL_DEFAULT_FILE_SIZE) is used.

Journal file can NOT be expanded indefinitely by design. A full journal is archived appending suffix "1" and a new journal file is created: this is called "rotation process". The number of old journals must be kept is determined at creation time:

• the program can specify it setting file_num field of struct jf_journal_file_opts_s

• if the program does not specify it, the value of environment var JF_JOURNAL_NUM is used

• if environment var JF_JOURNAL_NUM is not set, the default value (see hard wired constant JF_JOURNAL_DEFAULT_FILE_NUM) is used.

A journal file rotates when "rotation threshold" is reached and a global sync point is asked by the application. "Rotation threshold" is a number in range (0 , 1.0)

Journal rotation threshold is determined at creation time:

• the program can specify it setting rotation_threshold field of struct jf_journal_file_opts_s

• if the program does not specify it, the value of environment var JF_JOURNAL_ROTATION_THRESHOLD is used

• if environment var JF_JOURNAL_ROTATION_THRESHOLD is not set, the default value (see hard wired constant JF_JOURNAL_DEFAULT_ROTATION_THRESHOLD) is used.

Cache associated to a journaled file is determined at open time:

• the program can specify it setting field cache_size_limit of struct jf_journal_file_opts_s of struct jf_journal_opts_s of struct jf_file_open_opts_s

• if the program does not specify it, the value of environment var JF_JOURNALED_FILE_CACHE_SIZE is used

• if environment var JF_JOURNALED_FILE_CACHE_SIZE is not set, the default value (see hard wired constant JF_CACHE_FILE_DEFAULT_LIMIT) is used.

Yes, utility jf_bench is the official tool.

First, libjf is a recent experimental piece of code, while stdio is a well tested one. Second, libjf is based on stdio to avoid wheel design. Last but not least, libjf has a reacher semantic that allows transactionality, while stdio does not support transactions.

Applications that use "safe" synchronization (disk synchronization) tend to use twice the time when moved from stdio to libjf. Applications that use "fast" synchronization (buffer flush) tend to slow down a lot (4-5 times) when moved from stdio to libjf.

Because stdio does not provide a rollback function. Because stdio does not provide a synchronization function for more than one stream/file descriptor: your system may crash after synchronization of first stream/file descriptor and before synchronization of second stream/file descriptor.

There are many:

• filesystem type

• storage type (EIDE, SATA, SCSI, etc...)

• device type (native, RAID, DRBD, crypto, etc...)

• RAM and cache size and speed

• CPU type and speed.

If your application is CPU intensive and occasionally write something to disk, don't mind about libjf slow down. If your application writes a significative amount of data on disk, you can expect a slow down between 5% and 20%. If your application is I/O intensive, the results of jf_bench utility can help you guessing how elapsed time will increase and how CPU, user and system, time will increase. jf_bench does nothing with data written and read to/from disk so it should be the worst case your application might reach.

Yes, the slow-down introduced by libjf is correlated to the type of write an application requires. jf_bench utility program can help you with average results and pattern specific results.

Yes, jf_bench prints on terminal average results, but you can ask it to supply all the raw data in CSV and/or XML format.

Yes, you may specify different parameters changing the constants defined in the source code and recompiling it. The official version of jf_bench might change these values in the future: no one know "the right values"...

At this time libjf is "alpha" software and no optimization work has been done.

Sometimes default journal size is not sufficient for benchmark execution and environment variable JF_JOURNAL_SIZE must be tuned to a value higher than default; you may use this command before execution to set journal size at 256 Mbytes:

export JF_JOURNAL_SIZE=268435456