From email@example.com Wed May 17 14:43:08 2006
Date: Wed, 17 May 2006 14:38:12 -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, firstname.lastname@example.org, email@example.com
Subject: ext3 developer interlock call meeting minutes (May 17th, 2006)
ext3 developers interlock call May, 17th, 2006
RH: Stephen Tweedie, Don Howard, Linda Wang
CFS: Andreas Dilger, Alex Thomas
IBM: Theodore Ts'o, Suparna Bhattacharya,
Badari Pulavarty, Dave Kleikamp, Mingming Cao
BULL: Jean Pierre Dion, Laurent Vivier, Jean-Noel Cordenner,
Mingming posted the new ext3_fsblk_t patches (patch 5-7) to ext2-devel
last night: http://marc.theaimsgroup.com/?l=ext2-
The full series(total 7) now is at
The first 6 patches should expand ext3 from 8TB to 16TB, and the last
one on the series convert ext3_fsblk_t to sector_t type and enables >32
bit ext3 support in kernel.
This series should be used as the base to re-base other 64 bit ext3
Review patch 5-7 (sct and andreas?)
Review the ext3 code to see if the values on the RHS of a assignment to
ext3_fsblk_t type is able to support >32-bit (Mingming)
Alex incremental patches accroding to sct review comments:
and the 2.6.17-rc3 based full extents(with review comments) is at:
48 bit support for extents:
Review 48 bit support for extents patch (sct)
rebase the 48bit support patch with ext3_fsblk_t patches (Alex?
preallocation bit reservation in 48 bit extent (Alex)
Discussed about the proposed solution.
Rebase the 64bit-metadat patch to 2.6.17-rc4 and on top of the
ext3_fsblk_t patches (Laurent/Bull)
Address the block group offset addressing for groups across 16TB
boundary, according to the proposed solution. (Laurent)
Make sure the in-kernel super block fields are consistent with current
e2fsprog super block (Laurent/Bull)
Badari posted the proposed patch at:
And this updated patch on top of ext3_fsblk_t series:
Stephen raised the question whether we want to support 64 bit(32bit
+32bit) on-disk i_file_acl in this series (which means take more bits
from the inode). Andreas proposed we go with 48 bit i_file_acl for now
and later enlarge the default inode size and make it 64 bit, probably
together with other things we want to extend in inode and 64 bit extents
Address the issue with on-disk i_file_acl is >32 bit, but in-kernel
i_file_acl is 32 bit (due to sector_t is 32 bit if CONFIG_LBD) is not
latest & greatest patch is at:
The remaining work is to look at sector_t-jbd patch, review the
sector_changes to see if they are all necessary and convert to
Badari & Mingming will follow on sector_t-jbd,
Badari will look at 64 bit jbd support in e2fsprogs
6. e2fsprog changes
Laurent posted e2fsprog 1.38 based changes
Plan to repost the series against latest e2fsprogs
Ted to send out the tar
sorry, incomplete sentence above.
Ted to send out the tar ball of the current e2fsprogs tree to the list
for people who will work on e2fsprogs to support >32 bit ext3.
Laurent to rebase the BULL's e2fsprogs changes against Ted's e2fsprog
I found this quick tutorial about how to start using the e2fsprogs
Mercurial repository at:
2. Next steps
-- code changes
-- kernel source integration/maintain
-- e2fsprogs changes?
7. external patch deposit
Currently the patches are located at
Once Ted init the cvs deposit for ext2 project on sf, we could move the
patch series to cvs on ext2.sf.net.
For folks who want to have access to cvs tree on ext2.sf.net and don't
have account on sf.net, please create one and send to Ted.
Ted is going to check if cvs service is enabled for ext2.sf.net project.
Don is working on open a wiki page on one of the fedoracore website, and
will send out a follow email.