----- Original Message ----- > This looks like a big indicator that get_blocks is the wrong > interface for fiemap. Hi Christoph, 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. 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