From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC][PATCH] expose get_block via inode_operations Date: Wed, 23 Apr 2008 08:59:38 +0100 Message-ID: <20080423075938.GY27459@ZenIV.linux.org.uk> References: <20080422181824.GA2852@unused.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org To: Josef Bacik Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:56017 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753982AbYDWH7j (ORCPT ); Wed, 23 Apr 2008 03:59:39 -0400 Content-Disposition: inline In-Reply-To: <20080422181824.GA2852@unused.rdu.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Apr 22, 2008 at 02:18:24PM -0400, Josef Bacik wrote: > Hello, > > In order to add a generic FIEMAP support for all filesystems that do not > necessarily have extents (ie ext2/3), it is necessary to have direct access to > the filesystems get_block function. The reason for this is because in certain > cases (again ext2/3) the filesystem has the ability to map as many contiguous > blocks together at once, which would be far more efficient than calling ->bmap() > over and over for all of the blocks in the inode. In order to accomplish this I > would like to expose the filesystems get_block function via an inode operation. > This would allow me to create a simple generic FIEMAP function that could be > used on all fs's and be a bit more efficient that FIBMAP, and it would clean up > where we are passing get_block_t everywhere. ITYM "bugger up". Strong NAK; do not breed methods that do not even make sense for a lot of class instances. This, BTW, is a general principle - the same reason why ->read_inode() is gone, for example. If you have a function that needs fs-dependent callback and can be safely called only by specific fs (== relies on fs properties), by all means, make it a library helper and have your fs call it. Passing whatever callbacks it wants explicitly. With fs being responsible for choosing to use that library helper. get_block semantics can't be even defined for generic filesystem; it's not that "this fs or this file doesn't do that operation", it's "operation can't be defined in terms that make sense for all filesystems".