From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Efficient handling of sparse files Date: Mon, 28 Feb 2005 21:49:56 +0000 Message-ID: <20050228214956.GA21481@mail.shareable.org> References: <20050228174419.GC2910@dhcp-48-160.Connectathon.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeremy Allison , linux-fsdevel@vger.kernel.org, Matthew Wilcox Received: from mail.shareable.org ([81.29.64.88]:33963 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S261755AbVB1VuI (ORCPT ); Mon, 28 Feb 2005 16:50:08 -0500 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: > I'd resist any interface that exposes implementation details like that. > The user program shouldn't know anything about block allocations. A database or file scanner that must read a lot of data can benefit from having even a rough idea of the layout of the data on disk. When you have to scan a lot of data, the performance improvement from sweeping across a disk in block order can be significant - more so than trying to schedule lots of asynchronous I/O for the elevator to sort. But despite this use, ->bmap is not ideal for that type of optimisation because it does not always correspond to position on the physical device. -- Jamie