Ext4 file system(testing) silently entered in Linux kernel-2.6.19 onwards

praka123 · 22-04-2007, 04:51 PM

Quote:

The ext4 development branch has now been integrated into the mainline since kernel 2.6.19. This branch is still under development.

http://www.bullopensource.org/ext4/

Quote:

Ext4 Filesystem
===============

This is a development version of the ext4 filesystem, an advanced level
of the ext3 filesystem which incorporates scalability and reliability
enhancements for supporting large filesystems (64 bit) in keeping with
increasing disk capacities and state-of-the-art feature requirements.

2. Features
===========

2.1 Currently available

* 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

2.1 Previously available, soon 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

2.2 Candidate features for future inclusion

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)
* persistent file preallocation (e.g for streaming media, databases)

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.

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.

http://www.bullopensource.org/ext4/files/ext4.txt

Ext4 Wiki:
http://ext4.wiki.kernel.org/

Project Webpage:
http://www.bullopensource.org/ext4/

Also on ext4:
http://kernelnewbies.org/Linux_2_6_1...384bdc34e9785b

Quote:

EXT 4 is an evolution (not a redesign from zero) of EXT3. EXT3 never was, and never intended to be, a "state-of-the-art" filesystem (being fair, it was just about adding a journal to ext2 + some features like htree) but rather a solid, reliable filesystem. EXT3 has been quite successful, and despite of the age of its design it works surprisingly quite well in a wide variety of workloads from modern desktops to some big iron SMPs (even if it's not "the best" in some of those workloads). EXT4 is a development and experimental feature. EXT4 will incorporate scalability and reliability enhancements for supporting large filesystems (64 bit) in keeping with increasing disk capacities and some of the "state-of-the-art" feature requirements. But the version in 2.6.19 is missing lots of the features that are already developed but not merged, so it's not useful even for benchmarking.

Hope ext4 improves Linux experiance.

freebird · 22-04-2007, 05:41 PM

Nice Info.Will we see ext4 in the coming quarter atleast in some distros.
Also it seems they are including on-line defragmentation for ext4 and ext3 too in coming versions.

Quote:

Online Defragmentation