[haiku-development] [gsoc2011] New File System

  • From: Ankur Sethi <get.me.ankur@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 27 Mar 2011 02:11:40 +0530

Hi,

I'm Ankur Sethi, an IT student from New Delhi.

I've been reading Dominic Giampaolo's Practical File System Design With BFS.
I'm currently working on a BFS implementation for Linux using FUSE. It doesn't
do anything yet, but I hope to have rudimentary read only support soon.

Code: http://github.com/GeneralMaximus/bfs-fuse. WARNING: nothing
works.

My GSoC proposal is, essentially, this: write a new filesystem for Haiku based
on the current implementation of BFS. Focus on fixing the deficiencies in the
current implementation before adding new features.

A list of improvements I want to make to BFS follows. It's based on
http://dev.haiku-os.org/wiki/BFSIssues and the limitations outlined in Dominic's
book. Plus, of course, some nice-to-have features.

- Replace the block bitmap with a B-tree, or a pair of B-trees a la XFS.
- The block bitmap in BFS is a contiguous array of bytes. Perhaps it would be
  better to store it in a way that allows for easy resizing. This would allow
  quick and cheap resizing of partitions. NTFS is interesting in this regard.
  It treats pretty much everything, including the block bitmap, as a file.
  Thoughts?
- Store some of the file data in the inode smalldata.
- Get rid of the fixed size log. Once again, we could learn something from
  NTFS here, which treats the log as a file.
- Speed up concurrent access to the log. One log per allocation group?
- Fine grained access control lists, for when we have multiuser in R2 ;)
- There appears to be a limit on maximum file size (34GB). Figure out a way to
  fix this. Or cheat and just increase the number of blocks mapped by a block
  run?
- Copy-on-write clones.
- Efficient sparse file storage. This might require changes to the filesystem
  interface. Will that be a problem?
- And while we're on a break-all-backward-compatibility spree, add support for
  hard links.

I'll modify this list as I make my way through Practical File System Design.
I'm also looking at some other filesystems (most notably NTFS, XFS and btrfs).

There are a few features I would personally love to see in BFS2. Implementing
these would take much more time than one GSoC affords, but here they are,
for what they're worth:

- Versioning. This could pave the way for a powerful backup tool that relied on
  the filesystem to do the heavy lifting.
- Wear leveling and garbage collection for SSDs.
- Compression.
- Block-level checksums.
- Encryption.

I think it would also be a good idea to get a filesystem benchmark running on
Haiku. That way, we could look at some concrete performance statistics.
I'll see if I can get IOzone (http://www.iozone.org/) to run on Haiku.

Thoughts? Opinions?

-- 
Ankur Sethi
(GeneralMaximus on IRC and elsewhere)

Other related posts: