Re: How to add new fields into inode?

[Andreas Dilger <adilger@dilger.ca>]

On Feb 25, 2015, at 4:02 AM, Konstantin Khlebnikov <khlebnikov@yandex-team.ru> wrote:
> 
> Currently I'm working on (yet another attempt of) project id and quota
> for ext4. Obviously I want to add new u32 field into inode for holding
> it's project id.
> 
> As I see policy for that isn't well defined:
> 
> Kernel tries to allocate extra space according to sizeof(struct
> ext4_inode). If EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE is set then it takes
> maximum of sizeof, s_want_extra_isize and s_min_extra_isize.
> 
> Libext2fs always allocates space for it's own structure and in some
> cases checks s_want_extra_isize but without checking related feature.

That is likely a bug in libext2fs.  This feature was written because
some people were concerned about requiring extra inode features on a
filesystem that was upgraded from an older kernel where the reserved
fields were fewer.  In many cases, it is not critical if some field
at the end of the inode is present or not, but in other cases (maybe
project quota?) it is important that there is always space for saving
this data.

We have a patch for e2fsck which allows expanding the i_extra_size on
all in-use inodes in the filesystem to ensure that it meets at least
s_min_extra_isize.  New inodes will always reserve the needed space.

http://git.hpdd.intel.com/tools/e2fsprogs.git/commitdiff/6a7efec02c4d01b6bd951fef7d1c8c78f0426aa4
http://git.hpdd.intel.com/tools/e2fsprogs.git/commitdiff/89555784b583ff1dd48e31ff276a4ad0421172b0

If there isn't enough space in the inode for the extra bytes, then
e2fsck will prompt the user to delete an xattr from the inode, or
abort e2fsck (in a safe manner, nothing will be one in preen mode).

> Thus in some cases default extra size of inodes doesn't depend on
> present features and changes if we add new fields into structure.
> For example expected output of some unit tests depends on that value.
> 
> Question is: it's ok to waste some bytes for unused fields at the of
> inode or default extra size should depend on actually enabled features?

I think it is preferable that the i_extra_size not be larger than what
is actually used.  If some feature like project quota is enabled on an
existing filesystem, then e2fsck could be run to expand the inode size
to the needed size,  It would also be possible for the kernel to grow
i_extra_size to cover the new field, or return an error to userspace
at the time the new project quota is being set on the file (either
explicitly or by rename into a project quota-enabled directory).

Cheers, Andreas