Revision as of 16:18, 4 April 2011 by Ckujau
Ext4 Developer Interlock Call: 05-10-06 Minutes
Attendees: Stephen Tweedie, Don Howard, Andreas Dilger, Theodore Ts'o, Suparna Bhattacharya, Avantika Mathur, Dave Kleikamp, Mingming Cao, Jean Pierre Dion, Laurent Vivier, Jean-Noel Cordenner, Ratchov Alexandre
- 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.
- 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.
- 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.
- Laurent works with Stephen to drive this get fixed
- Stephen brought about a key issue with current on-disk xattr: we only have 32 bit to store EA block. We have to support xattr 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 xattr. 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.
- on-disk extents: variable length vs 48 bit/64 bit fixed length: Stephen mentioned that we ought to make the btree search of the 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. Stephen 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.
- 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.
- 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?
- 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.
- The things not covered are the e2fsprogs changes. To be discussed.
- Action: Laurent, Ted?
- 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?
- 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?
- After the next things to be addressed:
- cvs tree on ext2.sf.net
- rebase current patches to linus kernel
- extents format
- 64bit JBD
- xttar support
- block group across 16TB issue
- we should post the next series of patches to lkml