lessfs & btier

This version of lessfs comes with a large number of changes and improvements.

• Lessfs now returns -ENOSPC by default when it runs out of space.
• Lessfs will now try to reuse deleted data chunks aggressively when it reaches MIN_SPACE_FREE – 3%.
• Lessfs uses a pool of threads to compress and write the data. Previously the threads would work on the incoming data queue without sorting the data. This would lead to data being written in random order to the blockdata file. Now the data is sorted so that less seeks are required when the data is accessed.
• When compiled to used BerkeleyDB lessfs now uses HASH databases for inuse and fileblock instead of BTREE databases. (Sorry). Again this increases performance with large data sets.

Lessfs now comes with a diesel Engine. As of release 1.4.0 it also supports Berkeley DB as backend for the meta data of the filesystem. Reason for adding support for Berkeley DB is not that it was sexy to introduce it. Nor that it was fun to write the code. I needed a very reliable back-end and speed was less important then reliability. While hamsterdb still looks promising, for now it does not fulfill the requirements.

Other changes:

Lessfs now waits until it recycles deleted data chunks in the ‘blockdata’ file. This is needed because the transactional databases may revert transactions to the last steady state when lessfs is shutdown uncleanly. If the actual data has been overwritten because of reusing deleted blocks then it would be possible that after reverting the transactions the filesystem would sustain data corruption. Lessfs now waits 10 * COMMIT_INTERVAL before the space of a deleted chunk of data is reused.

Please read the release notes if you want to upgrade from lessfs-1.x to this release.

If you want to try the Berkeley DB back-end then you can find additional information in: README.berkeleydb

Enjoy,

Mark Ruijter

Lessfs 1.3.3.12 adds support for hamsterdb to the listdb utility. When lessfs is used with batch replication the master will now close the replication log file after reaching ROTATE_REPLOG_SIZE or after 15 minutes, whichever comes first.

This version of lessfs introduces a number of new features. When the master is configured with REPLICATION_PARTNER_IP=-1 it will automatically create numbered replication logfiles. These log files can either be used with replogtool or you can transfer them to the  REPLICATION_WATCHDIR location of a slave. In this case the slave will import the replication log and rename it to replog.dta-SEQUENCE-processed when it is done.

The slave will not wait until the file is complete. So copy the files over the the REPLICATION_WATCHDIR location and rename them when they have been fully transferred.

For example:

for i in `ls replog.dta-*`; do cp $i /data/watch/.$i; mv /data/watch/.$i /data/watch/$i; done

Another new feature of this version of lessfs is that it can be compiled with –enable-memtrace

In this case lessfs will create a report about memory allocation in /tmp/lessfs_memleak.txt This option useful for debugging and development and comes with a very modest performance impact.

A nasty bug that causes lessfs to leak memory has been identified in hamsterdb. A pre-release of hamsterdb that solves the problem can be found here : Hamsterdb 1.1.10

An official hamsterdb release can be expected shortly.

This version of lessfs introduces a brand new tool: replogtool

replogtool makes it possible to manually synchronize a lessfs slave server with the master server by simply copying the masters replogfile to the slave and apply it with replogtool like this:

lessfs-1.3.3.9/examples# ./restart.sh
lessfs-1.3.3.9/examples# umount /slave
lessfs-1.3.3.9/examples# cp /data/boot.img /master
lessfs-1.3.3.9/examples# umount /master
lessfs-1.3.3.9# ./replogtool -r /data/master/dta/replog.dta -c /etc/lessfs.cfg-slave
The replication log has been processed

lessfs-1.3.3.9# ./lessfs /etc/lessfs.cfg-slave /slave/
lessfs-1.3.3.9# md5sum /data/boot.img
md5sum0d8f9a783e3444135d33c4e19f63bc64  /data/boot.img
lessfs-1.3.3.9# md5sum /slave/boot.img
0d8f9a783e3444135d33c4e19f63bc64  /slave/boot.img

For now both the master and the slave need to be unmounted before the replication logfile can be copied to the slave. replogfile does not truncate the replication logfile after processing it. So do not forget to truncate or delete the masters replogfile after the file has been committed on the slave.

If you want a lessfs server to produce a replication logfile without using the lessfs replication protocol you can just specify these parameters in the configuration of the master:

REPLICATION=masterslave
REPLICATION_PARTNER_IP=-1
REPLICATION_PARTNER_PORT=201
REPLICATION_ROLE=master

Setting REPLICATION_PARTNER_IP to -1 indicates that lessfs should not attempt to connect to a slave server.

replogtool can also be used to analyze a replication log file. See the manual for more details.

This version of lessfs comes with slightly improved read performance. Parts of the lessfs_read routine have been reviewed and optimized. A potential race condition has been solved as well.

Lessfs-1.3.3.7 mostly a bug fix release. Only minor problems where solved.

See Changelog for details.

This release contains major changes of the replication code which is now much more mature. I also decided not to upload a separate SRPM. Lessfs comes with one spec file for tokyocabinet and one for hamsterdb. The SPEC files have changed so that upgrading the RPM does not change the lessfs init script or lessfs.cfg.

This is a bug fix release only. The most prominent bug that has been fixed was cache corruption when lessfs was used with hamsterdb. A problem with hamsterdb was also identified and solved. Hamsterdb will release 1.1.9 shortly.

Lessfs-1.3.3 is purely a bugfix release. Replication has been improved. A number of smaller issues with the hamsterdb backend have been solved as well.