From: Jeff Garzik <jeff@garzik.org>
To: Jan Kara <jack@suse.cz>
Cc: adilger@clusterfs.com, Theodore Tso <tytso@mit.edu>,
David Chinner <dgc@sgi.com>, Alex Tomas <alex@clusterfs.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [RFC] Ext3 online defrag
Date: Wed, 25 Oct 2006 14:08:21 -0400 [thread overview]
Message-ID: <20061025180821.GE19513@havoc.gtf.org> (raw)
In-Reply-To: <20061025175851.GA9940@atrey.karlin.mff.cuni.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.
Heck, according to my sf.net/projects/gkernel CVS log, you offered
some helpful review comments to me when I was implementing ext2meta ;-)
Jeff
next prev parent reply other threads:[~2006-10-25 18:08 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061023122710.GA12034@atrey.karlin.mff.cuni.cz>
2006-10-23 14:16 ` [RFC] Ext3 online defrag Theodore Tso
2006-10-23 14:31 ` Alex Tomas
2006-10-23 14:48 ` Andreas Dilger
2006-10-23 14:55 ` Jan Kara
2006-10-23 14:51 ` Jan Kara
2006-10-23 15:01 ` Eric Sandeen
2006-10-24 4:14 ` Jeff Garzik
2006-10-24 13:59 ` David Chinner
2006-10-24 14:51 ` Dave Kleikamp
2006-10-24 16:01 ` David Chinner
2006-10-24 16:26 ` Dave Kleikamp
2006-10-25 1:18 ` David Chinner
2006-10-25 2:30 ` Barry Naujok
2006-10-25 2:42 ` Jeff Garzik
2006-10-25 4:27 ` David Chinner
2006-10-25 4:48 ` Jeff Garzik
2006-10-25 5:38 ` David Chinner
2006-10-25 6:01 ` Jeff Garzik
2006-10-25 8:11 ` David Chinner
2006-10-25 17:00 ` Jeff Garzik
2006-10-26 1:40 ` David Chinner
2006-10-26 3:33 ` Theodore Tso
2006-10-26 6:36 ` David Chinner
2006-10-26 13:37 ` Theodore Tso
2006-10-26 14:40 ` Dave Kleikamp
2006-10-26 11:37 ` Jan Kara
2006-10-27 1:32 ` David Chinner
2006-10-24 14:52 ` Eric Sandeen
2006-10-24 19:44 ` Theodore Tso
2006-10-24 20:31 ` Russell Cattelan
2006-10-24 23:00 ` Andreas Dilger
2006-10-25 14:54 ` Jan Kara
2006-10-25 17:02 ` Jeff Garzik
2006-10-25 17:58 ` Jan Kara
2006-10-25 18:08 ` Jeff Garzik [this message]
2006-10-25 18:25 ` Jan Kara
2006-10-25 18:33 ` Jeff Garzik
2006-10-26 9:30 ` Andreas Dilger
2006-10-25 2:09 ` David Chinner
2006-10-23 14:45 ` Jan Kara
2006-10-23 15:14 ` Andreas Dilger
2006-10-23 16:03 ` Jan Kara
2006-10-23 17:29 ` Andreas Dilger
2006-10-25 18:36 ` Jan Kara
2006-10-25 18:41 ` Jeff Garzik
2006-10-26 15:25 ` Jörn Engel
2006-10-27 7:23 sho
2006-10-27 7:44 ` Alex Tomas
2006-10-27 13:53 ` Eric Sandeen
2006-10-27 14:05 ` Alex Tomas
2006-10-27 14:24 ` Eric Sandeen
2006-10-27 14:39 ` Alex Tomas
2006-11-15 9:54 ` Takashi Sato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061025180821.GE19513@havoc.gtf.org \
--to=jeff@garzik.org \
--cc=adilger@clusterfs.com \
--cc=alex@clusterfs.com \
--cc=dgc@sgi.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox