On Wed, Oct 25, 2006 at 11:33:16PM -0400, Theodore Tso wrote:
> On Thu, Oct 26, 2006 at 11:40:20AM +1000, David Chinner wrote:
> > We don't need to expose anything filesystem specific to userspace to
> > implement this. Online data movement (i.e. the defrag mechanism)
> > becomes something like:
>
On Thu, Oct 26, 2006 at 11:40:20AM +1000, David Chinner wrote:
> We don't need to expose anything filesystem specific to userspace to
> implement this. Online data movement (i.e. the defrag mechanism)
> becomes something like:
>
> do {
> get_free_list(dst_fd, location, len, li
On Wed, Oct 25, 2006 at 01:00:52PM -0400, Jeff Garzik wrote:
> On Wed, Oct 25, 2006 at 06:11:37PM +1000, David Chinner wrote:
> > On Wed, Oct 25, 2006 at 02:01:42AM -0400, Jeff Garzik wrote:
> > > On Wed, Oct 25, 2006 at 03:38:23PM +1000, David Chinner wrote:
> > > > On Wed, Oct 25, 2006 at 12:48:4
On Wed, Oct 25, 2006 at 08:36:56PM +0200, Jan Kara wrote:
> Yes, but there's a question of the interface to this operation. How to
> specify which indirect block I mean? Obviously we could introduce
> separate call for remapping indirect blocks but I find this solution
> kind of clumsy...
Agreed
> On Oct 23, 2006 18:03 +0200, Jan Kara wrote:
> > Andreas Dilger wrote:
> > > I would in fact go so far as to allow only a single extent to be specified
> > > per call. This is to avoid the passing of any pointers as part of the
> > > interface (hello ioctl police :-), and also makes the kernel
On Wed, Oct 25, 2006 at 08:25:30PM +0200, Jan Kara wrote:
> 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
> 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 rew
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 point
> 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 discus
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.
This was discussed years ago. Google f
On Wed, Oct 25, 2006 at 06:11:37PM +1000, David Chinner wrote:
> On Wed, Oct 25, 2006 at 02:01:42AM -0400, Jeff Garzik wrote:
> > On Wed, Oct 25, 2006 at 03:38:23PM +1000, David Chinner wrote:
> > > On Wed, Oct 25, 2006 at 12:48:44AM -0400, Jeff Garzik wrote:
> > > So why are you arguing that an in
> On Oct 24, 2006 15:44 -0400, Theodore Tso wrote:
> > First of all, we would need a way of allowing userpsace to specify
> > which blocks should be used in the preallocation.
>
> Presumably it could do this in the same way it will be specifying
> which blocks to relocate in the defragger - by pa
On 14:27, Andreas Dilger wrote:
> > + j = find_next_usable_block(-1, gdp, EXT3_BLOCKS_PER_GROUP(sb));
>
> I'm not sure why the "find_next_usable_block()" part is in here? At this
> point we KNOW that ret_block is not a block we should be allocating, yet
> it is marked free in the bitma
On Wed, Oct 25, 2006 at 02:01:42AM -0400, Jeff Garzik wrote:
> On Wed, Oct 25, 2006 at 03:38:23PM +1000, David Chinner wrote:
> > On Wed, Oct 25, 2006 at 12:48:44AM -0400, Jeff Garzik wrote:
> > So why are you arguing that an interface is no good because it
> > is fundamentally racy? ;)
>
> My poi
14 matches
Mail list logo
