Re: Updated ext4/jbd2 patches based on 2.6.19-rc1

Andreas Dilger
2006-10-06T06:41:05Z

On Oct 05, 2006 23:04 -0700, Andrew Morton wrote:
> On Thu, 5 Oct 2006 23:53:05 -0600
> Andreas Dilger <adilger@clusterfs.com> wrote:
> > No, we want to leave it at ext4dev for a while, to make it very clear
> > that this is still under development. We want to get the existing
> > patches upstream so they don't become completely unwieldy, and earlier
> > testing is also good, but it is not yet feature complete.
> >
>
> What features are missing?

There are several under discussion, whether they all make it in is
partly a function of how much time everyone has to work on them:
- improved file allocation (multi-block alloc, delayed alloc; basically done)
- fix 32000 subdirectory limit (patch exists, needs some e2fsck work)
- nsec timestamps for mtime, atime, ctime, create time (patch exists,
needs some e2fsck work)
- inode version field on disk (NFSv4, Lustre; prototype exists)
- reduced mke2fs/e2fsck time via uninitialized groups (prototype exists)
- journal checksumming for robustness, performance (prototype exists)

Features like metadata checksumming have been discussed and planned for
a bit but no patches exist yet so I'm not sure they're in the near-term
roadmap.

> Heck, what features does it have now? Guys, we cannot release this thing
> to the public without telling them what it is, how to use it, where to get
> the tools from and what the roadmap is.

Features now:
- ability to use filesystems > 16TB
- extent format reduces metadata overhead (RAM, IO for access, transactions)
- extent format more robust in face of on-disk corruption due to magics,
internal redunancy in tree

Features soon (previously available, to be enabled by default by "mkefs.ext4"):
- dir_index and resize inode will be on by default
- large inodes will be used by default for fast EAs, nsec timestamps, etc

Other features as above patches are committed.

The big performance win will come with mballoc and delalloc. CFS has
been using mballoc for a few years already with Lustre, and IBM + Bull
did a lot of benchmarking on it. The reason it isn't in the first set of
patches is partly a manageability issue, and partly because it doesn't
directly affect the on-disk format (outside of much better allocation)
so it isn't critical to get into the first round of changes. I believe
Alex is working on a new set of patches right now.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.