Date: Wed, 31 May 2006 17:47:13 -0700
From: Mingming Cao <firstname.lastname@example.org>
To: Stephen C. Tweedie <email@example.com>
Cc: Theodore Ts'o <firstname.lastname@example.org>, Andreas Dilger <email@example.com>,
Gerrit Huizenga <firstname.lastname@example.org>, Don Howard <email@example.com>,
Badari Pulavarty <firstname.lastname@example.org>,
Jean Pierre Dion <email@example.com>,
Laurent Vivier <Laurent.Vivier@bull.net>, Linda Wang <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
Subject: ext3 developer interlock call meeting minutes (May 31th, 2006)
ext3 developers interlock call May, 17th, 2006
RH: Stephen Tweedie, Don Howard, Linda Wang
CFS: Andreas Dilger
IBM: Badari Pulavarty, Dave Kleikamp, Mingming Cao
BULL: Jean Pierre Dion, Laurent Vivier, Jean-Noel Cordenner,
0. the latest series could be found at;
Mingming merged the following ext3_fsblk_t patches
into two patches and posted to lkml and ext2-devel:
Andrew take them in mm tree. The following patches at the top of the
list are also in mm tree now:
No furture action plan for this one.
Need to rebase the sector_t-jbd patch. (Badari?)
And some work to be done in the e2fsprogs
Rebase the 48bit support patch with ext3_fsblk_t patches is done.
Alex is working on credits stuff for extent.
Laurent posted the updated 64bit metadata patch to ext2-devel last week,
seems no furture action item for this one.
No futhure action for this patch.
7. e2fsprog changes
Alexandr posted the e2fsprogs changes based on current e2fsprogs deposit
Takashi Sato also posted some e2fsprogs changes that worth checking out
and possibly integrate.
Ted to review and comment?
8. increasing i_block size
Considering using some fields reserved for Hurd for the high 16 bits for
i_blocks for 48-bits total.
Discuss what fields to use in ext2-devel
9. 64k blocksize support
Takashi Sato worked on this as part of his patch:
Seems no harm to bring this part of patch to the series.
10.unlimited n_links support
Andreas mentioned it would make sense to include this patch to the
series, he will drive to post the patch to the list (after some work to
assure the compatibility issue)
We discussed issues raised up by Suparna in email about what to do for
now for preallocation. Two things:
1. Return EIO error when try to read uninitialized extents for now.
2. Making sure we never merge two extents into a one that are larger
than 2^15 blocks long.
We still need to make preallocation as INCOMPAT feature once the full
implementation in place. Seems probably a too big item for the first