> On Mar 5, 2016, at 10:46 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Sun, Mar 06, 2016 at 01:14:51PM +0900, Li Xi wrote: >> Project quota need use some extra field of inode for computing quota >> accounting, this patch tries to use ext2fs_get_next_inode_full() >> everywhere to read full inode into memeory. >> >> It also fixes a bug that only copy small inode in the function. >> >> Signed-off-by: Wang Shilong <wshilong@xxxxxxx> > > Um, no. Most of the places where we are currently using > ext2fs_get_next_inode() is because they **don't** need the full inode. > For example, consider debugfs's icheck command. Why would it need the > project quota id? Answer: it doesn't. > > If you think there is a bug, or some place where we should be using > the large inode, fine. Let's take a look at it. But doing a whole > sale conversion of ext2fs_get_next_inode() to > ext2fs_get_next_inode_full() makes e2fsprogs much less efficient, and > for no good purpose. Do you think it really makes e2fsprogs less efficient? The disk IO has already happened, and definitely included the whole inode even if only the small inode data was requested. The ext2fs block cache will still cache the whole inode block, so fetching the whole inode is no overhead. In contrast, several places in the code are doing extra work to fetch the large inode data after having fetched the small inode data. It is also fairly confusing in different parts of the code which "know" that the inode pointer is pointing to a full inode buffer, so it is a lot cleaner if we just always read the full inode data everywhere. Even better would be if the API explicitly just passed ext4_inode_large everywhere, which wouldn't break the ABI, but it might cause problems for anything that encodes the argument types (e.g. C++). At least if the e2fsprogs internal functions are reading the full inode the code is easier to understand. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
