From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey Mahoney Subject: Re: Access content of file via inodes Date: Wed, 06 Apr 2005 09:09:57 -0400 Message-ID: <4253DFA5.6000705@suse.com> References: <1112787226.21605.27.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Kathy KN (HK)" , Bryan Henderson , linux-fsdevel@vger.kernel.org Return-path: Received: from locomotive.csh.rit.edu ([129.21.60.149]:9011 "EHLO locomotive.unixthugs.org") by vger.kernel.org with ESMTP id S262195AbVDFNJ6 (ORCPT ); Wed, 6 Apr 2005 09:09:58 -0400 To: Anton Altaparmakov In-Reply-To: <1112787226.21605.27.camel@imp.csi.cam.ac.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Anton Altaparmakov wrote: > Jeff Mahoney wrote: > >>Kathy KN (HK) wrote: >> >>>What I meant by via blocks is to gain knowledge of the physical >>>blocks used by the inodes and retrieve the content from it directly, >>>by accessing b_data. >> >>The problem with that approach is that some filesystems may store part >>of the file outside of a complete block. For example, reiserfs "tails" >>will respond with -ENOENT on ->bmap. For files smaller than 16k, they >>are quite common. > > > This is one not true and two wrong! > > Looking at reiserfs code in the current 2.6 kernel it does: [...] > This will result in sparse blocks being returned whenever an error > occurs. Not what is desired... > > > The problem with ->bmap is that it cannot return error at all. It > either returns 0 for sparse or >0 for real block. ->bmap is the most > stupid interface I have ever seen... )-: If you ask me it should be > removed from the kernel without notice. Let all applications that use > it break. Who cares... It can always be replaced with a sensible > interface that returns errors like -ESPARSE, -ENOTAPPLICABLE, -EIO, > -ENOMEM, etc and doesn't assume that 0 is sparse... > Ugh. Mea culpa. I knew reiserfs_bmap would return less than useful results, and stopped there. I should have dug a little deeper. -Jeff -- Jeff Mahoney SuSE Labs jeffm@suse.com