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.) > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
