Re: [RFC] Ext3 online defrag

[Jan Kara <jack@suse.cz>]

> On Wed, Oct 25, 2006 at 07:58:51PM +0200, Jan Kara wrote:
> >   I've briefly looked at this and this kind of interface has some
> > appeal. On the other hand it's not obvious to me, how to implement in
> > this interface *atomic* operation "copy data from file F to given set of
> > blocks and rewrite pointers to original blocks with pointers to new
> > blocks". Something like this is needed for what we want to do...
> > Also if we'd like to implement operation like "add this block to file F
> > at position P" we have to make sure that all the necessary updates
> > (bitmap updates, inode updates, indirect block updates) go into one
> > transaction. Which basically mean that either ext3meta has to have a way
> > how to do this in a single operation, or we have to give userspace a way
> > to start/stop transaction and that starts to be really a mess because of
> > various deadlocks and so on.
> 
> Agreed, this issues exist.  But these issues exist independent of
> whether an ioctl or ext3meta is used.  It's all the responsibility
> of the implementor to define the interface.
> 
> My contention is that ext3meta interface method would be much more
> robust than ioctl.  It's a namespace inside which you can define any
> inodes/dirents you wish, for the operations you desire.
  I see. So you mean that in our ext3meta filesystem we'd have a file
named "add_this_extent_to_inode" and a file "reloc_inode_interval" and
they'd be fed essentially the same info as the current ioctl interface and
do the same thing as we currently do. Hmm, I don't find it that nice any
more but yes, this would work.

> Heck, according to my sf.net/projects/gkernel CVS log, you offered
> some helpful review comments to me when I was implementing ext2meta ;-)
  Looking at those mails it was already quite some time ago so I
forgot about it  ;)
								Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs