LinLogFS Frequently Asked Questions


Latest Modification: Feb, 28th. 2000

General Questions

What is LinLogFS?

LinLogFS is a project to implement a log-structured filesystem for Linux. The LinLogFS design takes a similar approach as the Sprite LFS or the 4.4BSD LFS with a few additional enhancements.

What is a Log-Structured Filesystem, Anyway?

A Log-Structured Filesystem (LFS) brings database-like semantics to disk writes. Disk writes are performed in a way that they are either recognized as "completed as a whole" or "hasn't happened at all" even in the case of a power failure/OS crash... whilst a write is in progress.

Basically, this can be achieved by writing to the disk in an append-only manner. So every change to the filesystem causes the updated information to be appended at the end of the log (i.e: no "update in place").

So, an LFS can offer you a variety of advantages:

Is a Log-Structured Filesystem the Same as a Journaling Filesystem?

Acutally, these two terms are often used as synonyms, but they aren't. Journaling can be viewed as a way that allows you to add fast crash recovery capabilities to "classic" filesystems without making big changes to the existing filesystem. This is done by applying the logging approach to filesystem metadata changes. Journaling filesystems put things like "block x allocated to file y" into a log that they use for replaying filesystem changes after a crash.

Project - Specific Questions

What is the current status of the project?

LinLogFS is currently not usable for end-users. It is still under development. The kernel implementation is fairly complete. However, LinLogFS still lacks a working cleaner, so free disk space is never reclaimed. (The cleaner is work in progress right now).

I Want to Give LinLogFS a try. -- How do I do This?

Since LinLogFS is still under development, the installation process is not streamlined yet. Furthermore, please keep in mind that you're running a Linux kernel extension that is still in its alpha/beta phase.

In order to give LinLogFS a try, you need:

After having obtained and unpacked the tarball, LinLogFS can be built performing the following steps (a detailed description of this process is included in the LinLogFS tarball):

(How) Can I Help the LinLogFS Project?

The original LinLogFS design and a "proof of concept" implementation will be my diploma thesis here at the Vienna University of Technology.

If you want to join in, there is no problem at all! Please don't hesitate to get in contact with me in case you're interesed. Any help on the project would be highly appreciated!

LinLogFS Progress has Been Slow. - Are you Still Working on it?

Yes! ;-) - But things should improve now, since my employer is now partly sponsoring the project...

LinLogFS and Other Filesystems

What is the Difference Between LinLogFS and Other Log-Structured Filesystems?

There are a few items that are particular to the design of LinLogFS:

Filesystem-independent core

LinLogFS consists of a filesystem independent "log" that provides an easy way to get transaction-like semantics to disk writes. Furthermore the log takes care of things like managing free disk space, providing necessary information for the cleaner and keeping multiple filesystem versions (see next item) out of each other's hair.

Filesystem personalities

A filesystem personality is responsible for providing all the necessary filesystem functionality that is required by the Linux VFS (Virtual Filesystem) for proper operation. A LinLogFS filesystem personality uses the services provided by the log for things like asking for available disk space or for writing multiple blocks to disk in a "transaction".

The ext2 sources of the Linux 2.2.x kernel have been modified to work with the filesystem independent core of LinLogFS as a filesystem personality.

Support for versioning

Versioning allows you to place more than one filesystem on a partition or allows you to have more than one version of a filesystem available.

Having more than one version of a filesystem available should be useful in many ways. For example, you can create a "snapshot" of a filesystem at a certain point in time and mount that snapshot readonly. So you have access to a consistent state of your filesystem (the snapshot you've just created) that you can use for backup purposes, for example, while your users can still access the filesystem in read/write mode.

Different checkpoint types

The design of LinLogFS allows multiple types of checkpoints that should make frequent commits (as they happen in the case of an NFS write, for example) more efficient.

What is the Relation Between ext2 and LinLogFS?

LinLogFS uses a modified version of the ext2 sources as a filesystem personality. So LinLogFS and ext2 use the same directory, inode and indirect block structures. Basically, the main difference is the way that files get laid out on disk and the mechanisms that are used for accessing inodes.

Why ext2 as Filesystem Personality?

There were several reasons why ext2 was chosen as LinLogFS's current (first?) filesystem personality:

More technical issues

Do you Have any Estimations About the Cleaning Overhead?

I can't give any LinLogFS--specific figures here for cleaning costs since LinLogFS is not (yet) having a cleaner. However, as a first step, I consider simply porting the 4.4BSD LFS cleaner to LinLogFS. However, there is a Usenix paper available discussing cleaning:
Trevor Blackwell, Jeffrey Harris, Margo Seltzer:
"Heuristic Cleaning in Log-Structured File Systems"
Proceedings of the 1995 Usenix Technical Conference on Unix and Advanced Computing Systems

The authors conclude "that trivial heuristics perform very well, allowing 97% of all cleaning on the most heavily loaded systems we studied to be done in the background". Furthermore, the implementation of data checkpoints in LinLogFS should keep the necessity of cascaded updates low.


Christian Czezatke, email: czezatke@complang.tuwien.ac.at