Message-ID: <455E30BC.9070705@us.ibm.com>
Date:	Fri, 17 Nov 2006 13:59:24 -0800
From:	Avantika Mathur LTC <mathur@...ibm.com>
To:	linux-ext4@...r.kernel.org
Subject: Ext4 devel interlock meeting minutes (Nov. 17, 2006)

Sorry they are a little late!  Here are minutes from the interlock call 
on Wednesday.

Thanks,
Avantika
----

Ext4 Developer Interlock Call: 11/15/06 Minutes

Attendees: Dave Kleikamp, Ted Ts'o, Jean-Pierre Dion, Valérie Clément, 
Jean-Noel Cordenner, Mingming Cao, Suparna Bhattacharya, Eric Sandeen, 
Avantika Mathur

- WIKI: Decided that we need to maintain one Wiki for Ext4. Ted will 
request a new wiki on kernel.org.

- Shaggy had sent out an Ext4 roadmap after the last call, but need to 
continue to plan when each feature will be stable and when the disk 
format can be freezed. This should be kept up to date on the Wiki.

- Ted is reviewing extents patches to e2fsprogs. There have been many 
changes to mercurial in the past week.

- Defrag Schemes: Detailed discussion of the different defrag schemes 
being discussed on the mailing list, and what requirements are needed 
for Ext4.  A summary of this discussion is below:


DEFRAG DISCUSSION
=================

(Ted and Eric, this is what I remembered from the discussion, please 
fill in any gaps or correct any mistakes in the summary.)

Trying to establish a clear direction for defrag, there has been a lot 
of discussion on the mailing list.  
The issues discussed were:

-- How the interface to the defrag should be implemented. Current ideas 
are using ioctls, system calls, or implementing as a filesystem.  Using 
ioctls was the method generally favored by Ted and Eric in the discussion.

-- Whether the implementation should be extent based or block based. Ted 
feels that this should be extent based, using indirect blocks if necessary

-- Should the block allocation policy be driven by user space or kernel 
space?

Prefer a user space driven policy, so that files that are accessed 
concurrently during system boot, can be put close together to speed up 
the boot process.  In this design the user space interface can specify 
an inode and logical block sequence to be put in a certain block 
location; if the space is available, the kernel will copy data and inode 
pointers.    
The user space interface will access bitmaps to locate free space.  It 
should also have the interface to specify a certain region to be 
reserved, and that region would be freed on the disk, so user space can 
move other files to that space.

-- Implementation

Ted believes the defrag should be implemented by specifying a region 
space for a file on disk, storing file data in page cache and copying 
the data from the page cache to the new physical blocks.  Then changing 
the mappings from the logical blocks to these new physical blocks.

Eric's approach is to identify the region on disk, generate a secondary 
inode for the file and allocate this space to the secondary inode.  Then 
copy the data from the original file to the new blocks, and replace the 
inode.  All file writes will need to be restricted during this process.
Ted's concerns with this approach is possible inconsistencies in the 
journal if the system crashes during this process, and also the 
inability to defrag files while they are being written to.



-
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

Powered by blists - more mailing lists