Ext3-devel/ext3minutes-20060510

From cmm@us.ibm.com Wed May 10 14:25:44 2006
Date: Wed, 10 May 2006 14:05:17 -0700
From: Mingming Cao <cmm@us.ibm.com>
To: Stephen C. Tweedie <sct@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger@clusterfs.com>, Gerrit Huizenga <gh@us.ibm.com>, Don Howard <dhoward@redhat.com>, Badari Pulavarty <pbadari@us.ibm.com>, Jean Pierre Dion <jean-pierre.dion@bull.net>, Laurent Vivier <Laurent.Vivier@bull.net>, Linda Wang <lwang@redhat.com>, shaggy@us.ibm.com, suparna@in.ibm.com, alex@clusterfs.com, avmathur@us.ibm.com, akpm@osdl.org
Subject: ext3 developer interlock call meeting minutes (May 10th, 2006)

ext3 developers interlock call May, 10th, 2006

Attendees:

RH:     Stephen Tweedie, Don Howard,

CFS:    Andreas Dilger

IBM:    Theodore Ts'o, Suparna Bhattacharya, Avantika Mathur,
Dave Kleikamp, Mingming Cao

BULL:   Jean Pierre Dion, Laurent Vivier, Jean-Noel Cordenner,
RATCHOV ALEXANDRE

1. sector_t patch (or kernel block variable type changes)

Stephen commented on sector_t patch, saying that there are some
unnecessary conversion to sectors and some bugs in the block reservation
code. Defining ext3_fsblk_t and ext3_grpblk first and classifying those
two type of blocks seems all necessary and should be done first.
Mingming had posted the ext3_fsblk_t based kernel block type changes to
the ext2-devel list and Stephen mentioned he will take a look. Mingming
to finish the last patch needed: convert the rest of filesystem blocks
to ext3_fsblk_t.

Extents patch also have some key block variables are treated as "int",
need to fix them, also need to classifying block variables and convert
them to the corresponding types (fs-wide vs. group-relative) in extents
patch.  Mingming agreed to work on a separate patch.


2. extents

Stephen commented overall the code looks good, although there are minor
things should be addressed. Andreas agree to follow up with Alex to
address Stephen's comments to extents patch posted to ext2-devel.


3. on-disk changes: potential issue with block group metadata across
16TB boundary.

Stephen raised the issue with the current 64bit-metadata patch: the
relative calc doesn't always work for block group's metadata across 16TB
boundary, where bitmaps or inode tables are actually past the 2^32
boundary. Ted and Andreas proposed to add a flag in each block group
descriptor to indicating it's relative or absolute addressing. Laurent
mentioned he proposed a fix in the email. sct to review Laurent's
proposal and comment, as well as send out the flag proposal to the email
list.

Action: Laurent works with sct to drive this get fixed


4. Support for xttar

Stephen brought about a key issue with current on-disk xttar: we only
have 32 bit to store EA block. We have to support xttar for 48/64 bit
ext3, this is needed for SELinux.

There are a long discussion about how to address this. The short term
solution seems we use some unused bits in the inode (either some bits
reserved for Hurd, or others sames unused for now) to support the high
16/32 bit block number for xttar.  Stephen/Andreas

Long term solution seems hasn't reach a agreement yet, but one thing
that brought up is the support to store EA in multiple blocks is
something we want badly for a long time, and should be considered in the
long term plan.

sct will drive the discussion the short term solution on the ext2-devel
list.

5. on-disk extents: variable length vs 48 bit/64 bit fixed length

Stephen mentioned that we ought to make the btree search of th extents
in the leaf block fast, so it seems at this moment keep the extents
fixed length in the tree is the right thing to do now.

The benefit of using variable length extents in inodes seems obvious,
question is whether we should variable length extents in the inodes. sct
suggested we could do compress and decompress extents in memory while
keep the on-disk extents in inode uncomressed. Some discussion among
sct, ted and andreas along that line.

In the long term we could support different extents format, using the
extents head magic. So the short term plan agreed in this meeting is to
keep 48 bit fixed extents in both inode and in the extents tree, and we
could have variable length extents in inode later.

Andreas also suggested block map based extents for sparse file, and sct
suggested that for any file, we could start storing direct blocks in the
old way until we need to convert them to extents

Action: probably no action here since the patch already does the 48 bit
fixed length extents. Probably someone need to look at the extents
header structure to double check the support for future different types
of extents and different extent_header structure inside inode are there.

6. persistent preallocation with extents:

sct suggested we steal a bit from the extents length to flag the
preallocated-but-not-initialized extent, since anyway we could not
allocate a chunk more than 128MB (limited by the block group boundary)
at this moment. No objection to this method.

Action: IBM will follow up drive the necessary changes(on-disk) to
support this in extents.

7. 64 bit JBD

Overall looks fine except some minor changes need to be done.

Action: Mingming will find a owner of this piece of work. Laurent? Zach?
Mingming?


8. patch source control
During the meeting we agreed to set up cvs tree on ext2.sf.net, checked
in the initial version, and rebase the current patch to the current
linus tree.

Action: Mingming to take over it.

8. The things not covered are the e2fsprogs changes. To be discussed.

Action: Laurent, Ted?

9. full support of 48 bit block number: make use of the high 16 bit in
the kernel.

This was not covered during the call. We will go after it through email.

Action: Alex?

11. issues discussed through emails but not covered in this call:
There are probably many. We should have a wiki page to document all the
stuff we discussed.

Action: RH is going to set up a wiki page for this work/effort.
Stephen? Don?

12. After the next things to be addressed:
-cvs tree on ext2.sf.net
-rebase current patches to linus kernel
-extents format
-64bit JBD
-sector_t
-xttar support
-block group across 16TB issue
we should post the next series of patches to lkml


13. Next meeting:
Next Wednesday (May 17th) 8:00am PCT, same time.


Since there are a lot of discussions happened during this call, it's
very likely that I missed some points. I encourage everyone to post the
proposed solution to the ext2-devel list.


Thanks,

Mingming


P.S. attached is last week's meeting minutes just for your reference.

> 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.
>
> Todo:
>
> 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.
>
> Todo:
>
> Ted is going to post the RFC of the compressed physical block number
> idea.
> 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
> changes:
>   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
>
> Todo:
>
> 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.
>
> Todo:
>
> Alex to post his latest version of mablloc for RFC.
>
> 6. Andreas proposed to post the 64 bit JBD patches first.
>
> Todo:
> 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.
>
> Thanks,
>
> Mingming