Re: [PATCH v1] ext4:Make FIEMAP and delayed allocation play well together.

[Eric Sandeen <sandeen@redhat.com>]

On 02/24/2011 10:15 AM, Yongqiang Yang wrote:
> 1. lookup dirty pages with specified range in pagecache.
>    If no page is got, then there is no delayed-extent and
>    return with EXT_CONTINUE.
> 2. find the 1st mapped buffer,
> 3. check if the mapped buffer is both in the request range
>    and a delayed buffer. If not, there is no delayed-extent,
>    then return.
> 4. a delayed-extent is found, the extent will be collected.

...

looking better, I think - please run this through scripts/checkpatch.pl,
there are a lot of whitespace issues etc.

> Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
> ---
>  fs/ext4/extents.c |  183 +++++++++++++++++++++++++++++++++++++++++-----------
>  1 files changed, 144 insertions(+), 39 deletions(-)
> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index ccce8a7..710d46e 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -3778,42 +3778,155 @@ int ext4_convert_unwritten_extents(struct inode *inode, loff_t offset,
>  /*
>   * Callback function called for each extent to gather FIEMAP information.
>   */
> +#define NR_PAGES_PER_TIME 128
> +
>  static int ext4_ext_fiemap_cb(struct inode *inode, struct ext4_ext_path *path,
>  		       struct ext4_ext_cache *newex, struct ext4_extent *ex,
>  		       void *data)
>  {
> +	struct page *pages[NR_PAGES_PER_TIME];

This is going to be a problem... stack usage of this function has jumped
from 96 bytes to 1K with this change.  I don't think this
can live on the stack.

I'll take some time to read over the rest of this, though, thanks.
It does pass xfstests 225, which exercises fiemap, but with the sync flag.

-Eric