[<prev] [next>] [day] [month] [year] [list]
Message-ID: <45AECD8B.1020806@linux.vnet.ibm.com>
Date: Wed, 17 Jan 2007 17:29:47 -0800
From: "AVANTIKA R. MATHUR" <mathur@...ux.vnet.ibm.com>
To: linux-ext4@...r.kernel.org
Subject: Ext4 devel interlock meeting minutes (Jan. 17 2007)
Ext4 Developer Interlock Call
Meeting Minutes January 17, 2007
Attendees: Mingming Cao, Dave Kleikamp, Jean Pierre Dion, Jean Noel
Cordenner, Valerie Clement, Suparna Bhattacharya, Eric Sandeen, Avantika
Mathur
- In the last call Ted proposed having a git tree for ext4 on
kernel.org, and Mingming then sent an email to the list requesting
everyone to resend latest versions of ext4 patches to put in these
tree. Mingming suggested that all bug fixes to ext4 should also be
copied to the git tree
- Eric asked if people would be interested if ext4 built better as
module. First by perhaps moving some ext4 headers from include/linux to
the ext4 directory; making it easier to build as a module
- Takashi posted updated patches to the mailing list. Mingming update
the ext4 wiki with status. Andreas and Takashi have been discussing what
the interface for online defragmentation should be. The next step is to
wait for a new patch set from Takashi, as there are some to do items.
- Preallocation: Amit Arora posted new patch set, Mingming reviewed the
patches and they look good.
-- The main outstanding issue is determining what the interface
should be: ioctl, fcntl, ftruncate, posix_fallocate. -- Eric does not
want to use ftruncate as it does not support creating sparse files.
-- Mingming asked if the return value should be how many blocks were
allocated, because when allocating accross holes, it may not allocate
number of blocks requested. Eric did not see allocation accross holes
to be a common case, and was not sure if the number of blocks allocated
will be useful. Eric will check how XFS handles this situation, it
could be helpful to try to keep semantics similar accross filesystems.
- Support for trillions of files in ext4: Mingming asked how XFS handles
a 64 bit inode number and binary incompatability issues.
-- XFS by default limits the inode number to 32 bit range; but can be
configured for 64 bit inode numbers. Eric suggested that as a
filesystem that is moving forward, ext4 could default to 64 bit inodes,
but be set to 32 bit inode if necesary.
-- Eric also mentioned looking at the scaling of mkfs block/inode
ratio based on filesystem size
-- fsck time on very large number of files is also an issue
- Mingming discussed the limitation on filesystem size by the fact that
all block group descriptors are stored in the first block; this limits
max filesystem size to 256 TB. We could enlarge the block group size to
store more block group descriptors or not store all descriptors in the
same block group. If meta block groups are turned on by default, this
limit could be resolved, but all peices for this feature may not be in
place.
- Encourage developers to update the ext4 wiki (ext4.wiki.kernel.org),
new patches page with details and status on features, It might be
helpful if there is a separate page on the WIKI for each feature.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists