From: "AVANTIKA R. MATHUR" <mathur@linux.vnet.ibm.com>
To: linux-ext4@vger.kernel.org
Subject: Ext4 devel interlock meeting minutes (Dec. 13 2006)
Date: Wed, 13 Dec 2006 15:42:59 -0800 [thread overview]
Message-ID: <45809003.5060403@linux.vnet.ibm.com> (raw)
Ext4 Developer Interlock Call: 12-13-06 Minutes
Attendees: Mingming Cao, Dave Kleikamp(Shaggy), Andreas Dilger, Eric
Sandeen, Ted Ts'o, Takashi Sato, Badari Pulavarty, Jean-Pierre Dion,
Jean Noel Cordenner, Valérie Clément, Avantika Mathur
Minutes can be accessed at:
http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
- The next interlock call will be in January
- Delayed Allocation and Multiple Block Allocation: Alex Tomas' patches
for delayed improves performance since it batches all writes to one area
of the disks, reducing number of seeks.
-- Online defragmention depends on delalloc and mballoc, these two
should be the priority to be pushed first.
-- Delalloc is not currently implemented on data=ordered mode; This is
a desired feature, but adding this support should not delay merging the
current patch.
- Preallocation: Mingming posted comment to the preallocation patches,
asking if preallocation should be implemented for block based files so
ext3 users could also use it. It was decided that it will be a rare
case where a user will want to add preallocation on existing block based
files, but might be a nice feature to have. Since zero-ing out the
blocks can take time and block applications, the ideal method would be
to first convert files to extents. If this was implemented, we would
want an in kernel converter utility that can convert from ext3 to have
all ext4 features and back.
- Backwards compatibility: Eric asked if maintaining ext3 features in
ext4 and format compatibility is necessary. Ted believes that up until
now it has not been too much work to maintain. With 64bit and extents
it may be more work, but also might be useful for some people. In the
future, if it is too much work or has a great impact on performance,
then backwards compatibility may be eliminated.
- Finer Timestamp: Ted will propose to the mailing list that nanosecond
timestamps are only supported in large inodes.
- Change Attribute:
-- Andreas asked the bull team why a new field in the inode is
necessary rather than using the i_version field, and also mentioned that
all code changes can be in mark_inode_dirty.
-- The ctime cannot be used for the change attribute because if the
server clock is incorrect, the ctime can go backwards in time.
-- semantics needed: nfsv4 and bull team require 32 bits, clusterfs
needs 64 bits.
next reply other threads:[~2006-12-13 23:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-13 23:42 AVANTIKA R. MATHUR [this message]
2006-12-14 0:08 ` Ext4 devel interlock meeting minutes (Dec. 13 2006) Andreas Dilger
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=45809003.5060403@linux.vnet.ibm.com \
--to=mathur@linux.vnet.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