Re: [RFC] Slimming down struct inode

Jan Engelhardt
2006-06-10T10:48:36Z

>1) Move i_blksize (optimal size for I/O, reported by the stat system
> call). Is there any reason why this needs to be per-inode, instead
> of per-filesystem?
>
I do not know much about XFS's realtime feature, but from what I have read
about it so far, it sounds to be a potential source where i_blksize might
differ from the regular filesystem. A guess, though.

>3) Move i_pipe, i_bdev, and i_cdev into a union. An inode cannot
> simultaneously be a pipe, block device, and character device at the
> same time.
>
Ah, finally this is being tackled. Let's recall Bernd's post:

"Mabe a regular file inode atribute can be put in that union, too?"

which made me think about members in struct inode that are only useful for
regular files. Is i_blkbits/i_blksize relevant for block special files? I
doubt that, since (as you mentioned above) it is (=should be) a
per-filesystem option, but block devices don't have to do anything with
filesystems in this respect. IOW,

struct ionde {
...
union {
struct regular_file {
unsigned int i_blkbits;
unsigned long i_blksize;
...
};
...
struct block_device *i_bdev;
struct cdev *i_cdev;
};
...
};

something like that. (Yes, i_blkbits/size should go into the sb, but maybe
there are other regular-files-only members.)

>6) Separate out those elements which are only used if the inode is open
> into a separate data structure (call it "struct inode_state" for
> the sake of argument):
>
> i_flock, i_mapping, i_data, i_dnotify_mask, i_dnotify,
> inotify_watches, inotify_sem, i_state, dirtied_when,
> i_size_seqcount, i_mutex, i_alloc_sem
>
> This is the motherload. Moving these fields out to a separate
> structure which is only allocated for inodes which are open will save
> a huge amount of memory. But, of course, sweeping through all of the
> code which uses these variables to move them would be a major code
> change. (We can do it initially with #define magic, but we will need
> to audit the code paths to see if it's always to safe to assume that
> inode is open before dereferencing the i_state pointer, or whether we
> need to check to see if it is valid first.)
>
Maybe doing it one at a time.

How long is inotify going to remain around?

>#6 is going to be the hard one, since it will involving touching the
>largest amount of code. But of course, the payoff will be quite big as
>well. Of course, memory is pretty cheap these days, which is probably
>
Cheap is relative :)

>What do people think? Is it worth putting together patches to do some
>or all of the above?

Jan Engelhardt
--