From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: Re: Efficient handling of sparse files Date: Mon, 28 Feb 2005 12:53:43 -0800 Message-ID: <422384D7.4060002@zabbo.net> References: <20050228174149.GA28741@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org Received: from tetsuo.zabbo.net ([207.173.201.20]:21960 "EHLO tetsuo.zabbo.net") by vger.kernel.org with ESMTP id S261733AbVB1Uxq (ORCPT ); Mon, 28 Feb 2005 15:53:46 -0500 To: Anton Altaparmakov In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > Please keep one thing in mind and that is that there are file systems > where ->bmap actually makes no sense whatsoever Of course, so return -ESORRY. > This is one of the reasons why noone should be using ->bmap. It is a > stupid interface that only fits very particular sets of file systems and > cannot be applied generically. No, it's a reason to only ask about the details of block mapping in cases where it actually makes sense (like, wanting to find out of concurrent file extension is getting good batched contiguous allocation, etc). Just because file systems x, y, and z can't answer the question meaningfully doesn't mean it isn't a reasonble thing to ask of file systems m, n, and o. Now, I'm not at all opposed to an explicit sparse-testing interface that doesn't confuse that functionality with querying specific block mappings. - z