Tux3 File-System Gains Initial FSCK Implementation

The Tux3 file-system has been in development for years while back on 1 January, the file-system work was resurrected. There's now an initial fsck implementation for Tux3.

Back on New Year's was when a status report came out that signaled the Tux3 file-system had advanced and was now more competitive with the EXT4 file-system. Less than one month later, there's now word of the initial fsck implementation for being able to fix the file-system in case of errors/problems.

The kernel mailing list announcement begins with, "Initial Tux3 fsck has landed. Things are moving right along in Tux3 land. Encouraged by our great initial benchmarks for in-cache workloads, we are now busy working through our to-do list to develop Tux3 the rest of the way into a functional filesystem that a sufficiently brave person could actually mount."

Tux3 developers have made it a goal to create an e2fsck-quality fsck for their file-system. Tux3 fsck uses a walker frame-work and will soon take advantage of their meta-data format checking methods and their walker framework was evolved from tux3graph, a graphical file-system structure dumper. "The walker is really sweet. You give it a few specialized methods and poof, you have an fsck. So far, we just check physical referential integrity: each block is either free or is referenced by exactly one pointer in the filesystem tree, possibly as part of a data extent. This check is done with the help of a 'shadow bitmap'. As we walk the tree, we mark off all referenced blocks in the shadow bitmap, complaining if already marked. At the end of that, the shadow file should be identical to the allocation bitmap inode. And more often than not, it is."

Tux3 fsck will continue to be heavily developed and is "not going to stay simple" and there's much more to come, per the kernel mailing list message.