From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Waychison Subject: Re: [patch 0/6][RFC] Cleanup FIBMAP Date: Mon, 29 Oct 2007 12:18:22 -0700 Message-ID: <472631FE.9070003@google.com> References: <20071026233732.568575496@crlf.corp.google.com> <20071029101001.4378a7cf@think.oraclecorp.com> <47260AB1.9000003@zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Mason , Anton Altaparmakov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Zach Brown Return-path: Received: from smtp-out.google.com ([216.239.45.13]:20942 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbXJ2TVw (ORCPT ); Mon, 29 Oct 2007 15:21:52 -0400 In-Reply-To: <47260AB1.9000003@zabbo.net> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Zach Brown wrote: >>> And another of my pet peeves with ->bmap is that it uses 0 to mean >>> "sparse" which causes a conflict on NTFS at least as block zero is >>> part of the $Boot system file so it is a real, valid block... NTFS >>> uses -1 to denote sparse blocks internally. >> Reiserfs and Btrfs also use 0 to mean packed. It would be nice if there >> was a way to indicate your-data-is-here-but-isn't-alone. But that's >> more of a feature for the FIEMAP stuff. > > And maybe we can step back and see what the callers of FIBMAP are doing > with the results they're getting. > > One use is to discover the order in which to read file data that will > result in efficient IO. > > If we had an interface specifically for this use case then perhaps a > sparse block would be better reported as the position of the inode > relative to other data blocks. Maybe the inode block number in ext* land. > Can you clarify what you mean above with an example? I don't really follow. Thanks, Mike Waychison