linux-ext4 - Ext4 devel interlock meeting minutes (Dec. 13 2006)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <45809003.5060403@linux.vnet.ibm.com>
Date:	Wed, 13 Dec 2006 15:42:59 -0800
From:	"AVANTIKA R. MATHUR" <mathur@...ux.vnet.ibm.com>
To:	linux-ext4@...r.kernel.org
Subject: Ext4 devel interlock meeting minutes (Dec. 13 2006)

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, Valérie Clément, 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.

-
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