Re: [PATCH v1 05/22] libext2fs: handle inline_data in block iterator function

[Theodore Ts'o <tytso@mit.edu>]

> diff --git a/lib/ext2fs/block.c b/lib/ext2fs/block.c
> index b8c6879..b194ca8 100644
> --- a/lib/ext2fs/block.c
> +++ b/lib/ext2fs/block.c
> @@ -345,6 +345,13 @@ errcode_t ext2fs_block_iterate3(ext2_filsys fs,
>  		return ctx.errcode;
>  
>  	/*
> +	 * If an inode has inline data, we needn't traverse its blocks
> +	 * because no block belong to this inode.
> +	 */
> +	if (inode.i_flags & EXT4_INLINE_DATA_FL)
> +		return ctx.errcode;

ctx.errcode is guaranteed to be zero here.  So it would be better to
return zero explicitly --- except I wonder if we might be better to
have ext2fs_block_iterate3() return an error code if it is called on a
file that has inline data.  If we did this, then in nearly all of the
places where we call ext2fs_has_inline_data(), the call could be
obviated, and replaced with a check for the error code from
ext2fs_block_iterate3() --- which gets called in nearly every single
place where we call ext2fs_has_inline_data().

I'm not that fond of ext2fs_has_inline_data() because it doesn't
actually do that much, and it also might encourage application
programmers to use it even when they have access to inode data
structure, but instead of doing something like this:

	   if (inode.i_flags & EXT4_INLINE_DATA_FL)

they'll out of laziness, do this instead

	if (ext2fs_has_inline_data(fs, ino)

Which is less efficient, since it means an extra call to
ext2fs_read_inode()

							- Ted