Date:	Mon, 26 Jan 2009 20:58:33 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fsdevel@...r.kernel.org, tux3@...3.org
Subject: Tux3 Report: Kernel development moved to Git mainline

Tux3 kernel development is now tracking Linus mainline, and will no
longer maintain compatibility with older kernels.  With the arrival of
delayed allocation, Tux3 now compiles only on kernels newer than
2.6.28.  A patch against v2.6.29-rc1 is here:

   http://tux3.org/patches/tux3-v2.6.29-rc1

Tux3 user space development remains in Mercurial:

   http://hg.tux3.org/tux3/

The Mercurial tree contains a complete, current copy of the fs/tux3
kernel files.  Our normal development mode is to add new functionality
and unit tests in user space, then port to kernel.  Sometimes it goes
the other way, with kernel changes backported to userspace.  In any
case, I use rsync to keep the Git and Mercurial kernel files in sync:

   rsync -t .../hg/tux3/user/kernel/* fs/tux3/ && make CONFIG_TUX3=y

There will be a public git tree soon.  For today, there is a patch
against Linus's tagged revision v2.6.29-rc1, the most recent one that
builds UML without a patch.  (I still do the majority of my Tux3 kernel
development on UML, while Hirofumi uses KVM and real machines, and
others use Xen.)

Status

Tux3 now uses delayed allocation, which is not just a performance hack
but a step in the direction of atomic commit.  Tux3 now keeps its
metadata blocks in a normal inode->mapping owned by the filesystem,
rather than the blockdev mapping, which has a different superblock than
the fs.  This sounds like a big change, but it was actually pretty
easy and not much code.  We made this change because block_dev.c is
dependent on buffer_head, and has its own ideas how metadata flushing
should be done.  Rather than fight with it, we switched.  It is nice to
be able to find our own superblock, given a buffer.  We will eventually
replace buffers entirely, with a new mechanism called block handles
that provides the block state we need with 16 bytes per page instead of
the 192 bytes worth of circular buffer list you get now with 1K blocks.

Tux3 has passed 27 hours of fsx-linux stress testing under memory
pressure, with delalloc and the new volmap metadata mapping.  We will
now say sayonara to stability for a while, as atomic commit goes in.
When atomic commit is in, the main structure of Tux3 is done, and we
plan to call for review at that time, leaving a bunch of features and
optimizations for later.  We expect Tux3 will perform decently as an
Ext3-class filesystem at that point, including crash recovery, though
it will be no benchmark champion before further optimization.

Build instructions

If you already have Linus's Git tree, please be nice and clone it
locally, otherwise:

   # Clone Linus's Git tree:
   git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
   cd linux-2.6
   git checkout v2.6.29-rc1

   # Get the current Tux3 patch and apply it:
   wget http://tux3.org/patches/tux3-v2.6.29-rc1
   patch <tux3-v2.6.29-rc1 -p1

   # Build linux with tux3:
   make defconfig
   make CONFIG_TUX3=y
   sudo make install

   # Check out the Tux3 user space Mercurial tree:
   hg clone http://hg.tux3.org/tux3/
   cd tux3/user
   make

   # make a tux3 filesystem
   sudo ./tux3 mkfs /dev/<testpartition>

Boot and mount!

   cat /proc/filesystems | grep tux3 && mount /dev/<testpartition> /mnt

Recovery after crash or unexpected shutdown is easy:

   tux3 mkfs <volname>

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists