[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061025175851.GA9940@atrey.karlin.mff.cuni.cz>
Date: Wed, 25 Oct 2006 19:58:51 +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 04:54:50PM +0200, Jan Kara wrote:
> > Yes, this sounds feasible. We could split the defrag ioctl into two
> > pieces (addition of given extent to a file and swapping of extents), which
> > can have generic interface...
>
> An ioctl is UGLY.
Agreed.
> This was discussed years ago. Google for 'Alexander Viro' and
> 'ext2meta'. That's a clean, flexible, extensible way to access metadata
> online. No need for ioctl binary translation across 32bit<->64bit, or
> any other ioctl issue.
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.
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
Powered by blists - more mailing lists