As discuss on the call yesterday, some folks (my self included) really want a TODO list to help them keep track of what things are left undone in e2fsprogs as we try to get ext4 out the door. Here is my initial list of items that still need addressing. Hopefully we can expand this list and document it somewhere like the ext4 wiki or the SourceForge bug tracker. - Rename uninit_groups to uninit_bg to be consistent with other defined features. Retain the old name for historical purpose. - The return value of ext2fs_super_and_bgd_loc() is not to be trusted. Document this in the source code. - Make sure ext2fs_super_and_bgd_loc() does not get used anywhere where the return value is expected to be accurate (aside from mke2fs). - Remove lazy_bg feature from being set in mke2fs. Feature has been declare a dangerous hack by its creator, remove it to avoid people building on top of it. - Add flex_bg meta-data grouping support. - Remove support for not zeroing the inode tables from the uninit_groups patches. This support is dangerous without a proper kernel thread that zeros them in the background when the filesystem is mounted. Depends on the lazy_bg removal. - Activate undo-manager in mke2fs only when inode tables are not being zeroed. Undo-manager is horribly slow if we need to store the information of all the blocks that have been zeroed during mke2fs. The amount of storage needed for the undo on a 16TB filesystem could be problematic. Depends on kernel thread inode table zeroing. - Make a 64-bit clean API that extends the existing one. The current API can not support larger than 32-bit blocks so a new set API calls is need in order to provide large filesystem support and retain backwards compatibility with the old API. - 64-bit bitmap interface. In order to support larger than 32-bit blocks, a new bitmap interface is needed that can retain ABI compatibility with the old one. -JRS -- 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
