From: Avantika Mathur LTC <mathur@us.ibm.com>
Subject: Ext4 devel interlock meeting minutes (Nov. 29 2006)
Date: Wed, 29 Nov 2006 11:02:11 -0800
Message-ID: <456DD933.2090304@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
To: linux-ext4@vger.kernel.org
Sender: linux-ext4-owner@vger.kernel.org

Ext4 Developer Interlock Call: 11-29-06 Minutes

Attendees: Mingming Cao, Eric Sandeen, Dave Kleikamp, Jean-Pierre Dion,=
=20
Val=E9rie Cl=E9ment, Jean-Noel Cordenner, Takashi Sato, Ted Ts'o, Avant=
ika=20
Mathur

- Preallocation:
  -- Suparna is has started working on implementation and will=20
temporarily use ioctls as interface.
  -- Discussed XFS implementation details posted by Eric, why there are=
=20
two methods, one zeroing out blocks, and the other setting flag in=20
preallocated extents.
  -- Eric will work on a proposal for preallocation implementation usin=
g=20
posix_fallocate and fcntl

- Nanosecond Timestamp:
  -- Reviewed status of Patch from Andreas Dilger in June
  -- Before moving forwars, we need to address design question of=20
whether nanosecond timestamps should be supported in older filesystems=20
with 128 byte inodes.  Will this feature be backported to ext3?
  -- Ted will reopen this issue on the mailing list
  -- Current plan is to only implement finer granularity timestamps for=
=20
larger inodes, unless there is someone who feels it is critical to have=
=20
them in current inodes.

- Defragmentation Patches:
  -- Takashi is working on addine improvements including support for=20
quotas.=20
  -- Will release new patch set in early December

- e2fsprogs: No updates to e2fsprogs since last week.
  -- New WIP released week ago; includes some recent patches including=20
struct defs for new features
  -- Ted is still working to merge extents patches and will report=20
progress next week

- New Wiki: ext4.wiki.kernel.org  Still a lot of work to be done to set=
=20
it up.
  -- We will keep all interlock agendas and minutes here
  -- Will create ext4 roadmap with details on implementations for each=20
feature

- Big Block Group patches:
  -- Val=E9rie posted patches last week
  -- Need a clearer description of why this feature is needed and what=20
the benefits are
  -- Decide whether it is a necessary feature and if all large=20
filesystems should be using it.
  -- Ted will reply to Val=E9rie's patches asking about specific benefi=
ts=20
and requirements.
  -- Current thoughts on benefits of large block group size:
     o increase file system size
     o reduce file fragmentation because less extents are needed for=20
large files
     o Reduce number of block descriptors, which reduces mkfs and fsck=20
times for large filesystems