linux-ext4.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).