From email@example.com Fri Jun 23 16:34:17 2006
Date: Fri, 23 Jun 2006 16:29:48 -0700
From: Mingming Cao <firstname.lastname@example.org>
Subject: [Ext2-devel] ext3 developers interlock meeting
We had weekly ext3 developers interlock meetings between some ext3 developers
for a few weeks. A lot of discussions about the 48 bit ext3 filesystem were covered
during last few meetings. All the previous meeting minutes are kept at ext3 wiki page
The interlock meeting is open for everyone when are interested in the ext3/ext4
design/development/testing/or general interest. The meeting is hosted on every
Wednesday at 8:00am PCT. Please contact me directly for the calling infos.
Here is the meeting minutes of ext3 developers interlock meeting on June 21st, 2006:
Stephen Tweedie, Mingming Cao, Theodore Ts'o, Andreas Dilger, Badari Pulavarty,
Suparna Bhattacharya, Takashi Sato, Laurent Vivier, Jean-Noel Cordenner,
Alexandre Ratchov, Don Howard, Avantika Mathur
1. The lastes 48bit ext3 patch series is still at:
Stephen pointed bugs that breaks current non-extent 32 bit
ext3 filesystem in this series:
* Wrong superblock fields.
The ext3_fs.h superblock definition is missing some new fields
defined by e2fsprogs, specifically mkfs-time and the journal
Action: Alexandra seems posted a patch for this, Stephen to review.
* Split read of journal tags on recovery.
Reading a journal block during recovery uses be64_read_split(),
which (if CONFIG_LBD is set) reads 64-bits, even when the
journal is using 32-bit entries! This leads to garbage in the
top 32-bits of the block numbers during recovery, and recovery
Action: Badari to ping Stephen to get it fixed.
* revoke.c still has an undefined construct:
int hash = (int)block ^ (int)(block >> 32);
where ">> 32" is not defined if "block" is already 32-bits wide
Action: Mingming fixed this. to be included in next release.
* there is also missing basic sanity checking for superblock/journal
compatibility flags for the available block device max size;
Action: Stephen will look at adding that.
2. Response to lkml's discussion about time for ext4
People who called in this week seems agree forking a new filesystem to
address the overall concern about stability impact to current stable ext3
The current plan is to start a new filesystem, called ext3-devel at this
moment. Once all it's stabilized, call it ext4. This is to prevent
some of the confusion about the versions of the this new filesystem
This meeting also discussed whether to turn on extent by default in this
ext3-devel filesystem. People probably will expect to see extent when they
using ext4 filesystem, but on that other hand, this also means the new
The current plan is not the split the JBD code.Current changes to JBD layer
is not so intrusive, just a few "ifs" to determine a 64 bit branch handling.
Andreas mentioned there are some patches that added checksum to JBD which we
wanted but relatively intrusive. We probably need to split JBD code when we
really get there.
Action: Stephen and Ted to draft a mail about proposed next steps and potential
issues for setting up the next "ext" filesystem -ext4, and send it to ext2-devel
for discussion before expose it to lklm. The projected plan to stabilize ext4 at
least take a year.
3. Currently the patches are hosted at ext2.sf.net/48bitext3/patches Plan to keep the quilt
styled patch series on ext2.sf.net. There is a wiki page for this project created
at Fedora website:
5. 32 bit ext3
The current ext3_fsblk_t patches that enables true 32 bit ext3 (8TB -> 16TB)
are in mm tree. Hopefully it get into 2.6.18 kernel and we could start to fork
the 48 bit ext4 filesystem from there.
We ought to support extent based directory, otherwise we can't address directories
located on disk beyond 2^32 blocks.
So we should move the extent patch prior to everything turn on 48 bit ext3. and get it
tested and integrated to the new filesystem first.
Action: Mingming to adjust the order of the series in next release when all the known
easy bugs fixed.
Alexandra from BULL posted the changes to enable extents in e2fsprogs (changes originally
from luster filesystem). Ted started to review them.