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
next 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.