----- Original Message ----- > On Wed, Oct 22, 2014 at 08:28:53AM -0400, Bob Peterson wrote: > > Yes, I thought about that. > > One of my early prototypes had a separate function used by fiemap. > > Function __generic_block_fiemap would call get_block() which > > returned an indication of a hole as it does today. When it saw > > the hole, fiemap called a new function get_hole_size() that was > > passed in like get_block. The problem is: it's grossly inefficient, > > since the new function get_hole_size() has to redo most of the work > > that get_block just did (at least in the case of GFS2). (Which in the > > case of a 1PB sparse file is non-trivial, since it involves several > > levels of metadata indirection). Combining it with get_block made it > > much more efficient. > > > > Making a separate get_block_map_fiemap() function just seems like an > > exercise in redundancy. > > I was thinking of replacing get_blocks entirely. We're not actually > using a buffer_head in fiemap, so the interface seems somewhat awkward. > If it used something like the iomap interface proposed by Dave long > time ago we'd have a much saner interface that for example XFS could use > as well. Hi Christoph. Can you send a link to the thread regarding Dave's iomap? proposal? I don't recall it offhand, so I don't know what it was or why it was never implemented. I assume you mean Dave Chinner. Maybe it's time to revisit the concept as a long-term solution. In the meantime, do you otherwise object to this patch as a short-term solution? Regards, Bob Peterson Red Hat File Systems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
