public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Avantika Mathur <mathur@linux.vnet.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ext4 devel interlock meeting minutes (March 14, 2007)
Date: Wed, 14 Mar 2007 14:51:42 -0800	[thread overview]
Message-ID: <1173912702.3886.7.camel@localhost.localdomain> (raw)
In-Reply-To: <45F87C03.506@linux.vnet.ibm.com>

On Wed, 2007-03-14 at 15:49 -0700, Avantika Mathur wrote:
> Ext4 Developer Interlock Call: 03/14/2007 Meeting Minutes
> 
> Attendees: Mingming Cao, Eric Sandeen, Ted Ts'o, Dave Kleikamp, Suparna Bhattacharya, Takashi Sato, Avantika Mathur
> 
> Minutes can be accessed at: http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call 
> 

just a little typo about the date of the conference on the wiki page,
you could fix that next time~

mingming
> 
> Ext4 git Tree:
> 
> - Shaggy and Eric fixed the recent problems with the nanosecond timestamps in the git tree
> 
> - There is a general problem that the git tree is not updated frequently
> 
> 	- Ted feels there is not enough testing done to feel comfortable updating to a new release
> 
>         -- Many of the patches added to the tree are not tested properly.  
> 	-- It would be helpful if people could pick up the tree and test it, and make sure all upstream merging criteria is met by ext4 developers.
> 
>     - Currently looking at methods of automating testing of each new git tree release on different architectures and benchmarks.
> 
>     - Slow code review is also slowing down ext4.
> 
> - Ted suggested maintaining a git tree that tracks the patch queue, so there can be multiple people working on the patch queue. 
> 	- When patches are stable, update the central git tree that can then be pushed upstream.
> 
> - Ted will start a second git tree, and initially put Shaggy and Mingming as additional users who can access the tree. 
> 
> 
> OLS:
> 
> - The Ext4 OLS Paper was accepted.
> 
> - Avantika presented the basic outline for the paper, Suparna had comments on the layout
> 
> 	- Rather than grouping features based on time (when they are going to be included), group them based on classification, 
> 		- i.e. scalability, block placement, new features.
> 
> 	- This way the paper can be used as a reference for people who want to learn about ext4
> 
> - Avantika will update the outline and send out a new version
> 
> - In the 2005 OLS ext3 paper, benchmarks tio dbench and filemark were used. 
> 	- Looking into different benchmarks to use in this paper. 
> 	- Eric suggested looking at CPU utilization test used by David Chinner in his XFS OLS paper last year.
> 
> 
> Preallocation:
> 
> - Amit has been working on implementing the fallocate systemn call
> 
>     - he was struggling with the mode bit and implementation on different architectures.
> 
> - Having difficulty in how to order the parameters on s390 architecture
> 
> - Suparna will ask Amit to post his current patches, so other can begin reviewing and helping out.
> 
> 
> i_version Patches:
> 
> - the high 32  bit of the i_version field is still required to support the full 64 bit i_version number NFSv4 requires
> 
> - The general consensus on the call was to use the i_extra_isize in the inode for the high 32 bits.
> 
>     - This would keep i_version completely separated from ctime
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2007-03-14 22:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-14 22:49 Ext4 devel interlock meeting minutes (March 14, 2007) Avantika Mathur
2007-03-14 22:51 ` Mingming Cao [this message]
2007-03-16 16:31 ` Randy Dunlap

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=1173912702.3886.7.camel@localhost.localdomain \
    --to=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mathur@linux.vnet.ibm.com \
    /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