On 02/23/2011 06:33 PM, Yongqiang Yang wrote: > On Thu, Feb 24, 2011 at 12:41 AM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >> On 2/23/11 9:59 AM, Yongqiang Yang wrote: ... >>> @@ -3830,7 +3845,8 @@ static int ext4_ext_fiemap_cb(struct inode *inode, struct ext4_ext_path *path, >>> * >>> * XXX this might miss a single-block extent at EXT_MAX_BLOCK >>> */ >>> - if (ext4_ext_next_allocated_block(path) == EXT_MAX_BLOCK || >>> + end = ext4_ext_next_allocated_block(path); >> >> I think this will fall down if you have: >> >> [ HOLE ][ DELALLOC ][ HOLE ][ ALLOCATED ] won't it? >> >> i.e. your "end" will be the first block of "allocated" right? > Yes, but it neglect nothing. If we want to deal his model, we need to > lookup dirty pages in specified range. > I think it's clearly a bug to return a delalloc range when in fact it's a hole... > We use pagevec_lookup_tag() instead of find_get_page() and check > BH_Delay of contiguous pages. Then, we can deal this model. Yes, that's how I was going to go about it before you jumped right in, thanks! :) -Eric -- 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
