LinLogFS Frequently Asked Questions
Latest Modification: Feb, 28th. 2000
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:
Fast crash recovery.
Easy support for logical volume management (resizing partitions)
Undoing (even multiple levels of) filesystem changes
Increased write performance (since all writes are performed in large, sequential
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
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
A spare partition to put a LinLogFS filesystem on
A Linux system (intel or Alpha should definitely work) running kernel
Linux kernel sources. (from http://www.kernel.org
for example). The current version is for Linux 2.2.14. Making it work for older kernel
versions might requrie some tweaking...
The LinLog sources from the download page.
Apply the LinLogFS patch to your kernel sources.
Configure your kernel with LinLogFS support enabled.
Compile the LinLogFS utilities. (This will give you a working mkfs utility to
create a LinLog filesystem on an empty partition.
Insert the LinLog kernel module into the running kernel (using insmod or modprobe).
mount the LinLog filesystem: (mount -tlinlog <testpartition> <testpoint>)
(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
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:
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.
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)
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?)
Re-using existing code reduces both the amount of work required for getting
LinLogFS to work.
ext2 is a very stable and well--working filesystem (so I can concentrate
on fixing LinLogFS-specific bugs... ;-))
ext2 will most likely be the Linux filesystem of choice for the forseeable
future. By using ext2 as a filesystem personality, enhancements in the
ext2 sources (such as ACL support or smart directory structures) should
be available for LinLogFS, too, without much effort.
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: