linux-ext4 - Re: [RFC] Ext3 online defrag

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061025182530.GC9940@atrey.karlin.mff.cuni.cz>
Date:	Wed, 25 Oct 2006 20:25:30 +0200
From:	Jan Kara <jack@...e.cz>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	adilger@...sterfs.com, Theodore Tso <tytso@....edu>,
	David Chinner <dgc@....com>, Alex Tomas <alex@...sterfs.com>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [RFC] Ext3 online defrag

> 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@...e.cz>
SuSE CR Labs
-
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