From: Avantika Mathur <mathur@linux.vnet.ibm.com>
To: linux-ext4@vger.kernel.org
Subject: Ext4 devel interlock meeting minutes (October 1, 2007)
Date: Mon, 01 Oct 2007 15:10:27 -0700 [thread overview]
Message-ID: <47017053.9060005@linux.vnet.ibm.com> (raw)
Ext4 Developer Interlock Call: 10/1/07 Meeting Minutes
Attendees: Mingming Cao, Aneesh Veetil, Dave Kleikamp, Akira Fujita, Ted
Ts'o, Jose Santos, Avantika Mathur, Jean-Pierre Dion
Minutes can be accessed at:
http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
EXT4 PATCH QUEUE
Multiple Block Allocation:
- Main outstanding issue is still need for better documentation of the code.
- Aneesh has marked the places that need explanation with fixme, and
Alex will be adding the needed comments. If this gets done quickly, we
can try to push this feature to 2.6.24
- Aneesh has asked for recommendations for a benchmark to run which will
test the mballoc allocator. Mingming suggested using dd and dbench, as
was done in the past for basic mballoc patches. To test the in-core
preallocation, kernel untar tests. Look at the file fragmentation after
running the test.
Large Block Patches:
- Mingming will post these patches to lkml for review
Uninitialized block groups:
- the uninitialized block group patches were posted to lkml and are in
the -mm tree.
JBD-stats through procfs patches:
- Ted will look at these patches and see if they are ready to push upstream
generic-find-next-le-bit:
- This function is only used in multiple block allocation patches. It
would not be a good idea to post this before mballoc, since the function
would be unused and may be cleaned up later.
Delayed Allocation:
- There has been an lkml thread about these patches.
- We have and approach that works for ext4, implemented at the vfs
level, but unless we can prove it can work for other filesystems, it
will not be accepted.
- Christoph Hellwig has commented that these patches will not work for
XFS.
- Mingming will try the patches with ext2/3, and Shaggy will try to find
time to test with JFS.
- If this approach works for other filesystems, we can try to push to
mainline as a placeholder.
truncate mutex patch:
- There is a performance concern with these patches. Mingming suggested
doing some testing to see what the actual performance regression is.
- Ted suggests breaking into two patches:
-- Patch 1 - Change the name of the mutex to block_mapped_mutex and
update comments to reflect the usage of the mutex
-- Patch 2 - Change to a read/write mutex
GENERAL
- Those patches we would still like to see in 2.6.24 need to be pushed
very quickly
- We should avoid having ext2/3 patches in the ext4-patch-queue and git
tree.
- Some of the patches that we just send to lkml for review end up being
pulled into the -mm tree, then Ted pulls them to the ext4-git tree, and
Andrew must remove from -mm. When we post for comments, we should use
[PATCH,RFC] to avoid this.
- Mingming suggested having a patch queue for the ext4-git tree for
easier review. Ted is also considering having a pu branch for the git
tree. Ted will think about what will work best.
- In the ext4-patch qDescription of patch include which version of -mm
the patch is in
next reply other threads:[~2007-10-01 22:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 22:10 Avantika Mathur [this message]
2007-10-02 5:58 ` Ext4 devel interlock meeting minutes (October 1, 2007) Andreas Dilger
2007-10-02 14:23 ` Eric Sandeen
2007-10-02 9:24 ` Valerie Clement
2007-10-02 11:36 ` Aneesh Kumar K.V
2007-10-02 14:12 ` Andreas Dilger
2007-10-02 18:10 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47017053.9060005@linux.vnet.ibm.com \
--to=mathur@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).