From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Subject: Re: [Cluster-devel] [PATCH][try6] VFS: new want_holesize and got_holesize buffer_head flags for fiemap Date: Wed, 22 Oct 2014 08:28:53 -0400 (EDT) Message-ID: <90509064.9314451.1413980933011.JavaMail.zimbra@redhat.com> References: <635673293.9099204.1413939501068.JavaMail.zimbra@redhat.com> <579956475.9102148.1413940195344.JavaMail.zimbra@redhat.com> <20141022060434.GA11237@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Alexander Viro , cluster-devel , Steven Whitehouse To: Christoph Hellwig Return-path: Received: from mx3-phx2.redhat.com ([209.132.183.24]:52881 "EHLO mx3-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932865AbaJVM3Q (ORCPT ); Wed, 22 Oct 2014 08:29:16 -0400 In-Reply-To: <20141022060434.GA11237@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: ----- 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