Re: [PATCH] fs: Add hooks for get_hole_size to generic_block_fiemap

[Dave Chinner <david@fromorbit.com>]

On Mon, Aug 11, 2014 at 01:01:04PM -0400, Bob Peterson wrote:
> Hi,
> 
> I'm just tossing this proof-of-concept patch out there to get some feedback
> from the community. The problem relates to the performance of fiemap on
> sparse files.
> 
> If you have a very big sparse file with huge holes, when those holes are
> encountered, function __generic_block_fiemap iterates for every block
> with "start_blk++;". This is extremely slow, inefficient and time consuming.
> A simple command like:
> 
>    dd if=/dev/zero of=/mnt/gfs2/filler-P bs=1 count=1 seek=1P
> 
> will cause some file systems to run continuously for days or weeks given
> a filefrag command, even though the file contains only a single byte.
> I encountered it with GFS2.
> 
> Sure, GFS2 does not need to call the generic fiemap. I can (and did)
> easily implement a GFS2-specific block_fiemap that detects and skips holes.
> My question is: Does it make sense to extend this to other file systems?
> 
> This patch just adds a hook in function generic_block_fiemap to call a
> fs-specific function to return a hole size. That way, the function
> doesn't have to do a block-by-block search when a hole is encountered.

Perhaps it would be better to create a new helper that can return
the hole size rather than extend the helper everyone is using. The
implementation can be shared, but then other filesystems can make
the choice of which implementation they use and you don't need to
touch them at all here. i.e. add generic_block_fiemap_holesize()
rather than modify the generic_block_fiemap() API.

> I realize not all file systems can make use of this concept, so I don't
> know if this is valuable or not. I thought I'd toss it out there to see
> what people think.

If you make it a separate interface, it doesn't matter whether other
filesystems can make use of it or not ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com