All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avantika Mathur LTC <mathur@us.ibm.com>
To: linux-ext4@vger.kernel.org
Subject: Ext4 devel interlock meeting minutes (Nov. 29 2006)
Date: Wed, 29 Nov 2006 11:02:11 -0800	[thread overview]
Message-ID: <456DD933.2090304@us.ibm.com> (raw)

Ext4 Developer Interlock Call: 11-29-06 Minutes

Attendees: Mingming Cao, Eric Sandeen, Dave Kleikamp, Jean-Pierre Dion, 
Valérie Clément, Jean-Noel Cordenner, Takashi Sato, Ted Ts'o, Avantika 
Mathur

- Preallocation:
  -- Suparna is has started working on implementation and will 
temporarily use ioctls as interface.
  -- Discussed XFS implementation details posted by Eric, why there are 
two methods, one zeroing out blocks, and the other setting flag in 
preallocated extents.
  -- Eric will work on a proposal for preallocation implementation using 
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 
whether nanosecond timestamps should be supported in older filesystems 
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 
larger inodes, unless there is someone who feels it is critical to have 
them in current inodes.

- Defragmentation Patches:
  -- Takashi is working on addine improvements including support for 
quotas. 
  -- 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 
struct defs for new features
  -- Ted is still working to merge extents patches and will report 
progress next week

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

- Big Block Group patches:
  -- Valérie posted patches last week
  -- Need a clearer description of why this feature is needed and what 
the benefits are
  -- Decide whether it is a necessary feature and if all large 
filesystems should be using it.
  -- Ted will reply to Valérie's patches asking about specific benefits 
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 
large files
     o Reduce number of block descriptors, which reduces mkfs and fsck 
times for large filesystems

             reply	other threads:[~2006-11-29 19:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29 19:02 Avantika Mathur LTC [this message]
2006-11-29 19:08 ` Ext4 devel interlock meeting minutes (Nov. 29 2006) Alex Tomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=456DD933.2090304@us.ibm.com \
    --to=mathur@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.