Message-ID: <462D42CA.50509@linux.vnet.ibm.com>
Date:	Mon, 23 Apr 2007 16:35:38 -0700
From:	Avantika Mathur <mathur@...ux.vnet.ibm.com>
To:	linux-ext4@...r.kernel.org
Subject: Ext4 devel interlock meeting minutes (April 23, 2007)

Ext4 Developer Interlock Call: 04/23/2007 Meeting Minutes

Attendees: Mingming Cao, Dave Kleikamp, Avantika Mathur, Ted Ts'o, 
Suparna Bhattacharya,
Jean-Pierre Dion, Jean Noel Cordenner, Valérie Clément, Jose Santos

Minutes can be accessed at: 
http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call

- Mingming proposed moving back to 8am PST meeting time, since the 6am 
time is inconvenient for
a few people.  This discussion will be continued through email, to find 
a time which works
for everyone.

- Next week's meeting will be canceled, unless there is anyone who would 
like to request a meeting.

PATCH STATUS

git-tree
- Mingming will be updating the git tree with extents-fix patches from 
Alex, i_flags patch from Honza, i_extra_isize patch from Kalpak.

Uninitialized Block Groups:
- The patch sent out by Andreas is against 2.6.16 and ext3.  Need to 
port this to current ext4, test and then add to git-tree.  Avantika will 
ask Andreas if he needs help with this.

JBD statistics:
- There is a patch to export JDB statistics to /proc.  In order to get 
this patch to mainline, there needs to be discussion about the correct 
place for the statistics; /proc or perhaps debugfs.

e2fsprogs:
- Ted will post the current e2fsprogs patches in progress. Ted has been 
working with these patches and making changes.
- Main work areas for making e2fsprogs compatible with extents and 64-bit.
    - block iterator: make a block iterator work with both extent and 
non-extent code. Code that is oblivious to extents will still work with 
the block iterator.  This has been written by Andreas Dilger.
    - extents: in order to preserve ABI compatibility, support for a new 
interface for extents which uses 64-bit logical and physical block 
numbers.  The block iterator then translate from on-disk to in-memory 
format.  This will allow for possible future increases of physical and 
logical block sizes in extents, without breaking ABI.
    - bitmaps in e2fsprogs: this will be discussed in more detail at the 
next meeting, after people have a chance to read related email.

preallocation:
- fallocate syscall interface:  the current plan, based on discussions 
on the mailing list, is to create a separate wrapper for s390 in glibc.  
Using regular parameter ordering for all other architectures, but a 
different order on s390.  Jakub Jelinek has said that the changes in 
glibc can be made pretty easily.
-  The preallocation patches in the ext4 git-tree are outdated, using 
the ioctl interface.  Once Amit re-posts the patches with the syscall 
interface, they will be updated in the git-tree as well.
- Mingming mentioned the need to flush preallocation metadata changes to 
disk if file size or file content is being tested.  Discussed doing an 
fsync at Bmap time.

TESTING
- extents testing
    - Discussed methods for testing extents on highly fragmented 
filesystems.
    - Jose will look into possible tests, including perhaps using the 
'aged' option in FFSB
    - Ted suggested creating a mountoption that creates a bad block 
allocator which it jumps to a new block group every 8 blocks.  This 
would force a very large number of extents, and may be a good test for 
extents.

- large filesystem
    - We would like to perform more testing on large (>16TB) filesystems
    - currently hardware limitations are preventing this testing.  We 
have tested 10TB raid dists, and 16TB loopback devices.  Avantika will 
look into creating very large sparse devices for testing.

- Large file deletion
    - Valerie had recently tested large file deletion on ext3/4, but did 
not see the expected performance gain with ext4 due to compact metadata 
when using extents.
    - Valerie will try re-running the test.  Jose will also be looking 
into this test.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists