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:
.bmap = reiserfs_aop_bmap,
Which is:
static sector_t reiserfs_aop_bmap(struct address_space *as, sector_t
block) {
return generic_block_bmap(as, block, reiserfs_bmap) ;
}
And generic_block_bmap is:
sector_t generic_block_bmap(struct address_space *mapping, sector_t
block,
get_block_t *get_block)
{
struct buffer_head tmp;
struct inode *inode = mapping->host;
tmp.b_state = 0;
tmp.b_blocknr = 0;
get_block(inode, block, &tmp, 0);
return tmp.b_blocknr;
}
It ignores any errors from get_block() and always returns tmp.b_blocknr.
Thus is get_block() fails, tmp.b_blocknr is 0 and hence 0 is returned,
i.e. a sparse block. Which is complete rubbish...
And get_block in this case in reiserfs is:
static int reiserfs_bmap (struct inode * inode, sector_t block,
struct buffer_head * bh_result, int create)
{
if (!file_capable (inode, block))
return -EFBIG;
reiserfs_write_lock(inode->i_sb);
/* do not read the direct item */
_get_block_create_0 (inode, block, bh_result, 0) ;
reiserfs_write_unlock(inode->i_sb);
return 0;
}
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>
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
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
