Date:	Fri, 12 Sep 2014 17:13:47 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 26/25] libext2fs: call get_alloc_block hook when
 allocating blocks

On Fri, Sep 12, 2014 at 06:17:53PM -0400, Theodore Ts'o wrote:
> On Fri, Sep 12, 2014 at 10:57:50AM -0700, Darrick J. Wong wrote:
> > 
> > > errcode_t ext2fs_alloc_blocks(ext2_filsys fs, blk64_t goal,
> > > 	  	              unsigned int *num_blocks,
> > > 			      char *block_buf, int flags, blk64_t *ret)
> > > 
> > > ... which can be used to efficiently allocate up to *num_blocks blocks
> > > at a time, much like the mballoc interface.  I suspect that would be
> > > useful for a number of different cases, including ext2fs_fallocate and
> > > mk_hugefiles.c.
> > 
> > Sounds familiar:  http://marc.info/?l=linux-ext4&m=139898612510491&w=2
> 
> Yes, but I'm thinking of something which is a superset of
> ext2fs_alloc_block2().  That is, that it should call the
> get_alloc_block hook (and also adding a possible get_alloc_blocks
> hook), and that a flag would control whether the data blocks would be
> zero'ed or not.  (Indeed, I was thinking originally of calling it
> ext2fs_alloc_block3.)

Ah, I see.  I _think_ the big difference between what you're talking about and
my new_range implementation is that new_range finds you a chunk of free blocks
that could be longer than what you asked for and lets you decide what to do
with them (like new_block does) whereas alloc_blocks3 (or alloc_range) would
find that chunk and call alloc_stats on just the piece you want.

I'd prefer the new_range feature since you can do some trivial preallocation
with it, but I'm open to an alloc_block3 too.

(I dislike the name alloc_block3, since we're really allocating a range.)

Anyway, we'll see what everyone thinks when the patch comes out in part 6.

--D

> > > What I'm currently wondering about is whether it's worth the interface
> > > complexity to have something like a "struct ext2fs_allocation_request"
> > > structure, so we can potentially add more hints that a future
> > > implementation might use, or whether that's not worth it.
> > > 
> > > What do folks think?
> > 
> > I'm not sure changing a struct vs. changing whatever parameters we feed into
> > that function is all that much different.  I guess you could get around
> > structure size changes by forcing callers to use a library allocator function.
> > But OTOH large allocations are probably rare.
> 
> We can also insulate against structure sizes by using padding fields,
> but the ultimate question is how complicated we want to make this
> interface.  We know it will be used by mk_hugeblock and the fallocate
> interface.  In theory it could be use by your fuse driver to do
> allocations more efficiently.  There is the question of whether it's
> worth it, although it has crossed my mind that this might be an
> interesting place to start experimenting with an eventual replacement
> of the buddy-bitmap implementation in mballoc with something that use
> in-memory rbtrees, for example....
> 
> 					- Ted
> --
> 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
--
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