From Ext4
Revision as of 16:19, 4 April 2011 by Ckujau (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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, Valerie Clement, 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.
Personal tools