From firstname.lastname@example.org Wed May 3 12:01:18 2006
Date: Wed, 03 May 2006 11:55:42 -0700
From: Mingming Cao <email@example.com>
To: Stephen C. Tweedie <firstname.lastname@example.org>, Theodore Ts'o <email@example.com>, Andreas Dilger <firstname.lastname@example.org>
Cc: Gerrit Huizenga <email@example.com>, Don Howard <firstname.lastname@example.org>, Badari Pulavarty <email@example.com>, Jean Pierre Dion <firstname.lastname@example.org>, Laurent Vivier <Laurent.Vivier@bull.net>, Linda Wang <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
Subject: ext3 64 bit filesystem interlock call meeting minutes (May 3rd, 2006)
Extents/64bit ext3 call 3rd, May 2006
Stephen Tweedie, Badari Pulavarty, Theodore Ts'o, Mingming Cao,
Andreas Dilger, ALex Thomas, Laurent Viver, Linda Wong,
Don Howard, Suparna Bhattacharya, Avantika Mathur
1. Linda gave a short introduction of the motivation: ext3 filesystem
capacity is an issue that customer is complaining about right now.
Target to get extents based patches to enlarge ext3 filesystem size
changes into upstream by mid of June. (late july is the hard deadline
to catch up with RHEL5).
2. Stephen talked about the scope of the work next: the focus right now
is the extents format: extents, and larger physical block numbers (48 or
64 or flexible compressed phy. block number). Plan is not to bundle
every discussed on-disk format changes into a single, larger logical
file block number and other things should be addressed seperatly at a
later time. Goal is get this set of patches(extents) into upstream
first, then we could work on other changes like timestamp/checksum/etc.
Mingming will post Alex and Laurent's patches(2.6.16 based, sector_t
patch+extents patch first) to lkml by end of Friday, with description.
Stephen to follow up and post comments
3. As to the format of extents, the key question to be decide is the
physical block number size(48 vs 64 vs compressed). Ted is going to post
a RFC of the compressed physical block method. Tt seems the extent
header has a version flag support that allow us to support both exisitng
customers from CFS using 48 bit block number, and allow the phy. block
number to grow to 64 bit. Jean Noel from BULL is working on supporting
both 48 bit and 64 bit block numbers.
Ted is going to post the RFC of the compressed physical block number
64 bit patches from Laurent will be discussed and followed up later,
after Mingming post the 48 bit based exents patch to lkml.
4. Ted discussed the e2fsprogs changes that are needed to support kernel
a) 32bit/64bit API is broken, need to look closely at the changes.
potentional solutions: have a major imcompatible version of e2fsprogs,
and ask the distro to ship two version of e2fsprogs; or build both 32bit
and 64 bit libaries in e2fsprogs.
b) fsck support for extents: currently seems extents check an repair are not supported
c) Laurent pointed out that e2fsprogs currently doesn't manage 64bit JBD
Ted will drive the effort to address the above issues.
5. Badari asked about whether the extents patch touched any ext3
journalling mode support code in ext3. Suparna clarified that the
ext3_***_writepages() are only changed in extents based delayed
allocation patch, so the current extent changes in Lauren'ts patch set
is pretty clean. Ted addressed the need for delalloc. Alex and Andreas
mentioned there is a new version of the mballoc that doesn't use a on-
disk seperate block bitmap. Conclusion is these are things to be
addressed at later point of time.
Alex to post his latest version of mablloc for RFC.
6. Andreas proposed to post the 64 bit JBD patches first.
Andreas, you will drive this, yes? (I seems missed the conclusion from
the discussion here)
7. The next meeting is scheduled a week later: May 10th, 2006, same time
(8:00am PCT). Mingming to send out the invitation later.
It seems pretty much the minutes from the call that I could remember.
Please feel free to fill the missing pieces, and welcome any comments.