Features Download
From: Daniel Phillips <lkml <at> phunq.net>
Subject: Tux3 report: New news for the new year
Newsgroups: gmane.linux.kernel
Date: Tuesday 1st January 2013 11:52:43 UTC (over 3 years ago)
Hi everybody,

The Tux3 project has some interesting news to report for the new year. In 
brief, the first time Hirofumi ever put together all the kernel pieces in
magical lab over in Tokyo, our Tux3 rocket took off and made it straight to

orbit. Or in less metaphorical terms, our first meaningful benchmarks
turned in 
numbers that meet or even slightly beat the illustrious incumbent, Ext4:

    fsstress -f dread=0 -f dwrite=0 -f fsync=0 -f fdatasync=0 \
          -s 1000 -l 200 -n 200 -p 3


        time       cpu      wait
        46.338, 1.244, 5.096
        49.101, 1.144, 5.896
        49.838, 1.152, 5.776


        time       cpu      wait
        46.684, 0.592, 1.860
        44.011, 0.684, 1.764
        43.773, 0.556, 1.888

Fsstress runs a mix of filesystem operations typical of a Linux system
heavy load. In this test, Tux3 spends less time waiting than Ext4, uses
CPU (see below) and finishes faster on average. This was exciting for us, 
though we must temper our enthusiasm by noting that these are still early 
results and several important bits of Tux3 are as yet unfinished. While we
not expect the current code to excel at extreme scales just yet, it seems
are already doing well at the scale that resembles computers you are
at this very moment.

About Tux3

Here is a short Tux3 primer. Tux3 is a general purpose LInux filesystem 
developed by a group of us mainly for the fun of it. Tux3 started in summer
2008, as a container for a new storage versioning algorithm originally
to serve as a new engine for the ddsnap volume snapshot virtual device:

    "Versioned pointers: a new method of representing snapshots"

As design work proceeded on a suitably simple filesystem with modern
the focus shifted from versioning to the filesystem itself, as the latter
is a 
notoriously challenging and engaging project. Initial prototyping was done
user space by me and others, and later ran under Fuse, a spectacular
contribution from one Tero Roponen. Hirofumi joined the team with an
utility that makes graphs of the disk structure of Tux3 volumes, and soon
charge of the kernel port. I stand in awe of Hirofumi's design sense,
work and general developer prowess.

Like a German car, Tux3 is both old school and modern. Closer in spirit to 
Ext4 than Btrfs, Tux3 sports an inode table, allocates blocks with bitmaps,

puts directories in files, and stores attributes in inodes. Like Ext4 and 
Btrfs, Tux3 uses extents indexed by btrees. Source file names are familiar:

balloc.c, namei.c etc. But Tux3 has some new files like filemap.c and log.c
help make it fast, compact, and very ACID.

Unlike Ext4, Tux3 keeps inodes in a btree, inodes are variable length, and
inode attributes are variable length and optional. Also unlike Ext4, Tux3 
writes nondestructively and uses a write-anywhere log instead of a journal.

Differences with Btrfs are larger. The code base is considerably smaller, 
though to be sure, some of that can be accounted for by incomplete
The Tux3 filesystem tree is single-rooted, there is no forest of shared
There is no built-in volume manager. Names and inodes are stored
And so on. But our goal is the same: a modern, snapshotting, replicating 
general purpose filesystem, which I am happy to say, seems to have just
a lot closer.

Front/Back Separation

At the heart of Tux3's kernel implementation lies a technique we call 
"front/back separation", which partly accounts for the surprising kernel
advantage in the above benchmark results. Tux3 runs as two, loosely coupled

pieces: the frontend, which handles Posix filesystem operations entirely in

cache, and the backend, which does the brute work of preparing dirty cache
atomic transfer to media. The frontend shows up as kernel CPU accounted to
Fsstress task, while the backend is largely invisible, running on some 
otherwise idle CPU. We suspect that the total of frontend and backend CPU
less than Ext4 as well, but so far nobody has checked. What we do know, is 
that filesystem operations tend to complete faster when they only need to
with cache and not little details such as backing store.

Front/back separtion is like taking delayed allocation to its logical 
conclusion: every kind of structural change is delayed, not just block 
allocation. I credit Matt Dillon of Dragonfly fame for this idea. He
the way he used it in Hammer as part of this dialog:

   "Comparing HAMMER And Tux3"

Hammer is a cluster filesystem, but front/back separation turns out to be 
equally effective on a single node. Of course, the tricky part is making
two pieces run asynchronously without stalling on each other. Which brings

Block Forking

Block forking is an idea that has been part of Tux3 from the beginning, and

roughly resembles the "stable pages" work now underway. Unlike stable
block forking does not reduce performance. Quite the contrary - block
enables front/back separation, which boosted Tux3 Fsstress performance
40%. The basic idea of block forking is to never wait on pages under IO,
clone them instead. This protects in-flight pages  from damage by VFS
without forcing page cache updates to stall on writeback.

Implementing this simple idea is harder than it sounds. We need to deal
multiple blocks being accessed asynchronously on the same page, and we need
worry a lot about cache object lifetimes and locking. Especially in
things can get pretty crazy. Hirofumi's work here can only be described by
word:  brilliant.

Deltas and Strong Consistency

Tux3 groups frontend update transactions into "deltas". According to some 
heuristic, one delta ends and the next one begins, such that all dirty
objects affected by the operations belonging to a given delta may be 
transferred to media in a single atomic operation. In particular, we take
that directory updates always lie in the same delta as associated updates
as creating or deleting inode representations in the inode table.

Tux3 always cleans dirty cache completely on each delta commit. This is not

traditional behavior for Linux filesystems, which normally let the core VM 
memory flusher tell them which dirty pages of which inodes should be
flushed to 
disk. We largely ignore the VM's opinion about that and flush everything,
delta. You might think this would hurt performance, but apparently it does 
not. It does allow us to implement stronger consistency guarantees than 
typical for Linux.

We provide two main guarantees:

   *  Atomicity: File data never appears on media in an intermediate state,

      with the single exception of large file writes, which may be broken
      across multiple deltas, but with write ordering preserved.

   * Ordering: If one filesystem transaction ends before another
      begins, then the second transaction will never appear on durable
      unless the first does too.

Our atomicity guarantee resembles Ext4's data=journal but performs more
data=ordered. This is interesting, considering that Tux3 always writes 
nondestructively. Finding a new, empty location for each block written and 
updating the associated metadata would seem to carry a fairly hefty cost,
apparently it does not.

Our ordering guarantee has not been seen on Linux before, as far as we
We get it "for free" from Tux3's atomic update algorithm. This could
prove useful to developers of file-based databases, for example, mailers
MTAs. (Kmail devs, please take note!)

Logging and Rollup

Tux3 goes out of its way to avoid recursive copy on write, that is, the 
expensive behavior where a change to a data leaf must be propagated all the

way up the filesystem tree to the root, to avoid altering data that belongs
a previously committed consistent filesystem image. (Btrfs extends this 
recursive copy on write idea to implement snapshots, but Tux3 does not.)

Instead of writing out changes to parents of altered blocks, Tux3 only
the parents in cache, and writes a description of each change to a log on 
media. This prevents recursive copy-on-write. Tux3 will eventually write
such retained dirty metadata blocks in a process we call "rollup", which 
retires log blocks and writes out dirty metadata blocks in full. A delta 
containing a rollup also tidily avoids recursive copy on write: just like
other delta, changes to the parents of redirected blocks are made only in 
cache, and new log entries are generated.

Tux3 further employs logging to make the allocation bitmap overhead largely

vanish. Tux3 retains dirty bitmaps in memory and writes a description of
allocate/free to the log. It is much cheaper to write out one log block
potentially many dirty bitmap blocks, each containing only a few changed

Tux3's rollup not only avoids expensive recursive copy on write, it
updating in a least three ways.

  * Multiple deltas may dirty the same metadata block multiple times but
     rollup only writes those blocks once.

  * Multiple metadata blocks may be written out in a single, linear pass
     across spinning media.

  * Backend structure changes are batched in a cache friendly way.

One curious side effect of Tux3's log+rollup strategy is that in normal 
operation, the image of a Tux3 filesystem is never entirely consistent if 
considered only as literal block images. Instead, the log must be replayed
order to reconstruct dirty cache, then the view of the filesystem tree from

dirty cache is consistent.

This is more or less the inverse of the traditional view where a replay 
changes the media image. Tux3 replay is a true read-only operation that
media untouched and changes cache instead. In fact, this theme runs 
consistently through Tux3's entire design. As a filesystem, Tux3 cares
updating cache, moving data between cache and media, and little else.

Tux3 does not normally update the media view of its filesystem tree  even
unmount. Instead, it replays the log on each mount. One excellent reason
doing this is to exercise our replay code. (You surely would not want to 
discover replay flaws only on the rare occasions you crash.) Another reason
that we view sudden interruption as the normal way a filesystem should shut

down. We uphold your right to hit the power switch on a computing device
expect to find nothing but consistent data when you turn it back on.

Fast Sync

Tux3 can sync a minimal file data change to disk by writing four blocks, or
minimal file create and write with seven blocks:

    "Full volume sync performance"

This is so fast that we are tempted to implement fsync as sync. However, we

intend to resist that temptation in the long run, and implement an
fsync that "jumps the queue" of Tux3's delta update pipeline and completes 
without waiting for a potentially large amount of unrelated dirty cache to
flushed to media.

Still to do

There is a significant amount of work still needed to bring Tux3 to a 
production state. As of today, Tux3 does not have snapshots, in spite of
being the main motivation for starting on this in the first place. The new 
PHtree directory index is designed, not implemented. Freespace management 
needs acceleration before it will benchmark well at extreme scale. Block 
allocation needs to be much smarter before it will age well and resist read

fragmentation. There are several major optimizations still left to
We need a good fsck that approaches the effectiveness of e2fsck. There is a

long list of shiny features to add:  block migration, volume growing and 
shrinking, defragmentation, dedupilcation, replication, and so on.

We have made plausible plans for all of the above, but indeed the devil is
the doing. So we are considering the merits of invoking the "many hands
light work" principle. Tux3 is pretty well documented and the code base is,
not completely obvious, at least small and orthogonal. Tux3 runs in
in two different ways: the tux3 command and fuse. Prototyping in user space
a rare luxury that could almost make one lazy. Tux3 is an entirely
effort driven by volunteers. Nonetheless, we would welcome offers of 
assistance from wherever they may come, especially testers.


CD: 3ms