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... > > <rant> > 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... > </rant>
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
