From: "Jose R. Santos" <jrs@us.ibm.com>
Subject: Ininitial e2fsprogs TODO list (please expand)
Date: Tue, 15 Apr 2008 11:52:16 -0500
Message-ID: <20080415115216.1f6868de@gara.konoha.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
To: linux-ext4 <linux-ext4@vger.kernel.org>
Sender: linux-ext4-owner@vger.kernel.org

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