On Sat, Mar 05, 2016 at 11:27:25PM -0700, Andreas Dilger wrote: > 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. I'm concerned about all of the extra memory allocation and deallocation that we would need to do. If you have a million inodes, that's a million malloc()'s and free()'s. > 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. Can you point at some of these places? See below, but I think it's a lot more complicated to do what you are suggested. > 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. For the inode structure, for better or for worse, we have a "caller allocates" convention. So we can't just fill in the full inode unless the caller explicitly requests it, and tells us how much space it has available. Also, if the caller passes in a pointer to struct ext2_inode, the library can't assume it's a full inode. Fortunately, in the vast majority of the places where the library needs to look at the inode, it doesn't need to look at the full inode. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
