The Fox File System has been deprecated in favor of a new design I'm working on. That design will reach here when ready. The new design localizes data and takes advantage of expected behavior of hard drives. It also offers a O(1) Inode look-up.

The Features page has all the features I was planning for FoxFS. Doesn't use trees like ReiserFS but it should be easy to walk the directory tree starting at /.

Click one of the menus at the top of the page and select an option.

This site needs a major rework. Right now I'm working on the third prototyping of FoxFS. The first one was ill-done; the second was destroying the first by making everything objects. This third one, currently codenamed Project 9TK (Nine Tailed Kitsune), leverages a lot of things.

Features of Project 9TK include:

• Journaling

  Meta-Journaling allows for single-block transactions to be written to the journal. These can contain a mirror of the entire block, allowing for defragmentation and reorganization of fragment and meta-data blocks safely and efficiently.

• Built-in compression

  In order to increase the speed of file access, built-in compression will be available. The compression will typically be restricted to operate on input of given units and pack output however is most fit, allowing easy random seeking and modification. Compression is not very CPU intensive, so the trade-off should lower both disk access and usage if done right.

• Localized related data to decrease needed disk seeks, reads, writes

  Inode blocks will contain an inode list and meta-data for the inodes; and fragment blocks will contain the fragment information table and the fragment data. In this way, reading the entire block in and manipulating it in memory will allow Inodes to appear to be of varying sizes and support varying options, such as extra XATTRs, large files, and long dates.

• Inode blocks

  To simplify maintaining an inode table, Inode blocks are used. This scheme references Inodes by an 80 bit identifier comprised of the block the Inode is in and the Inode index in the block [BLOCK][I]. This calculates out to seek to the exact position of the Inode on disk; however, in normal operation, the Inode block would be read in in its entirety to take advantage of related data localization.

  Another advantage to this is that the inode list is automatically expansible based on need with no overhead. A file system only needs one Inode: /. As more files and directories are created, more Inodes are added to the block that houses /. If that block fills, then another Inode block is allocated. If that block has all inodes in it freed, it is freed itself. Thus, Inodes are created and destroyed as needed.

• Fragment blocks to pack small chunks of files and meta-data into
• Object Oriented meta-data

  Meta-data will be referenced as objects of varying types. This will allow the need for larger files to manifest as varied types of meta-data which perform the same function. This is also useful for fixing issuse such as the 2038 bug, which can be fixed just with simple patches to the filesystem driver. Of course there is a meta-data object specifically for XATTR as well.

• Safe, fault-tolerant online resizing in either direction to facilitate logical volume managment and the moving and resizing of partitions while in use without risk of corruption

Also, you may be interested in the ANLFS, my NFS clone. Severe work in progress on the side.