linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Ext4 devel interlock meeting minutes (Jan. 17 2007)
@ 2007-01-18  1:29 AVANTIKA R. MATHUR
  0 siblings, 0 replies; only message in thread
From: AVANTIKA R. MATHUR @ 2007-01-18  1:29 UTC (permalink / raw)
  To: linux-ext4

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-01-18  1:29 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-18  1:29 Ext4 devel interlock meeting minutes (Jan. 17 2007) AVANTIKA R. MATHUR

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