linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "AVANTIKA R. MATHUR" <mathur@linux.vnet.ibm.com>
To: linux-ext4@vger.kernel.org
Subject: Ext4 devel interlock meeting minutes (Jan. 17 2007)
Date: Wed, 17 Jan 2007 17:29:47 -0800	[thread overview]
Message-ID: <45AECD8B.1020806@linux.vnet.ibm.com> (raw)

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.

                 reply	other threads:[~2007-01-18  1:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=45AECD8B.1020806@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;
as well as URLs for NNTP newsgroup(s).