From Fedora Project Wiki
From cmm@us.ibm.com Wed May 3 12:01:18 2006 Date: Wed, 03 May 2006 11:55:42 -0700 From: Mingming Cao <cmm@us.ibm.com> To: Stephen C. Tweedie <sct@redhat.com>, Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger@clusterfs.com> Cc: 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 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. 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