Ext4 Developer Interlock Call: August 27, 2007 Meeting Minutes
Attendees: Mingming Cao, Takashi Sato, Dave Kleikamp, Ted T'so, Jose
Santos, Andreas Dilger, Avantika Mathur
Minutes can be accessed at:
http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
E2fsprogs
- Ted has started working on extents support in e2fsprogs; and will try
to send these patches out before kernel summit.
- Valerie has a cleanup patch which will be posted the mailing list this
week.
Kernel Patches
- Preallocation: This feature is in 2.6.23-rc1, but ia64 and s390
architectures still need support for the system call. Mingming will ask
the architecture maintainers to add this support.
- Inode Version: The overwrite case still needs to be addressed. Calls
to ext4_mark_inode_dirty() still depend on changes to the timestamp.
The plan is to update the i_version on every call to file_update_time();
and add a mountoption and flag to the superblock so the update is only
made if i_version is enabled and filesystems not using the feature are
not affected.
- Delayed / Multiple Block Allocation: Both patches are in the patch
queue. Mingming was wondering which feature should be pushed first.
Both patches need to be posted for review. The delayed allocation
patches should not be pushed through the ext4 tree, but rather through
the -mm tree.
- Uninitialized block groups: Avantika sent out an updated patch which
is ready to be merged to the patch queue.
- Flexible Block Groups - Jose had sent an email with questions and
details for plans for the feature. He has decided not to use
uninitialized inode tables, and will be sending out another email to the
list with more details about the future plans for this feature..
Automated Testing
- Avantika has a set of automated tests that run whenever the
ext4-patch-queue is updated. She will change the scripts to kick off
two suites; one only testing the stable patches in the queue, and one
testing the entire patch queue
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
