On Dec 30, 2019, at 8:19 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 
> On Mon, Dec 30, 2019 at 08:36:06PM +0900, Wang Shilong wrote:
>> blocks_from_inode() did not return wrong inode blocks, and
>> ext2fs_inode_i_blocks() is not taking EXT4_HUGE_FILE_FL into account
>> at all, while the some callers deal it correctly, some not. This patch
>> try to unify to handle it in ext2fs_inode_i_blocks() to return.
>> blocks(based on 512 bytes)
> 
> I don't really want to change the functionality of
> ext2fs_inode_i_blocks().  First of all, it's in a shared library, so
> if there are any binaries which were expecting the old behavior, that
> could get surprising.  Secondly, its name is confusing and so we're
> better off creating a new function ext2fs_get_stat_i_blocks() which
> makes it clear that we function is using units of 512 byte sectors,
> instead of either the file system block size, or the raw i_blocks
> value from the inode.
> 
> Two other things about your patch.  First of all, the filefrag command
> in debugfs was intended to print the number of file system blocks, so
> it was correct as written.  Secondly, please note the blkcnt_t is a
> signed type (because the block iterator functions use negative values
> to indicate various kinds of metadata blocks), while blk64_t is an
> unsigned type.  So using blkcnt_t as a temporary value and returning
> it in a function which has a return type of blk64_t will (righly)
> trigger compiler warnings.
> 
> Here's the patch I've checked into the maint branch of e2fsprogs to
> address the issue you've identified.

No patch is attached?

Cheers, Andreas