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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
