On Dec 30, 2019, at 8:19 AM, Theodore Y. Ts'o <tytso@xxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
