From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH] fs: Add hooks for get_hole_size to generic_block_fiemap Date: Wed, 13 Aug 2014 09:03:36 +1000 Message-ID: <20140812230336.GM26465@dastard> References: <998022701.4933159.1407775414413.JavaMail.zimbra@redhat.com> <526123861.4943408.1407776464284.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Bob Peterson Return-path: Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:3298 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbaHLXDw (ORCPT ); Tue, 12 Aug 2014 19:03:52 -0400 Content-Disposition: inline In-Reply-To: <526123861.4943408.1407776464284.JavaMail.zimbra@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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