[Cluster-devel] Disentangling address_space and inode
Steven Whitehouse
swhiteho at redhat.com
Wed Jun 10 09:27:04 UTC 2020
Hi,
On 09/06/2020 13:41, Matthew Wilcox wrote:
> I have a modest proposal ...
>
> struct inode {
> - struct address_space i_data;
> }
>
> +struct minode {
> + struct inode i;
> + struct address_space m;
> +};
>
> struct address_space {
> - struct inode *host;
> }
>
> This saves one pointer per inode, and cuts all the pagecache support
> from inodes which don't need to have a page cache (symlinks, directories,
> pipes, sockets, char devices).
>
> This was born from the annoyance of going from a struct page to a filesystem:
> page->mapping->host->i_sb->s_type
>
> That's four pointer dereferences. This would bring it down to three:
> i_host(page->mapping)->i_sb->s_type
>
> I could see (eventually) interfaces changing to pass around a
> struct minode *mapping instead of a struct address_space *mapping. But
> I know mapping->host and inode->i_mapping sometimes have some pretty
> weird relationships and maybe there's a legitimate usage that can't be
> handled by this change.
>
> Every filesystem which does use the page cache would have to be changed
> to use a minode instead of an inode, which is why this proposal is so
> very modest. But before I start looking into it properly, I thought
> somebody might know why this isn't going to work.
>
> I know about raw devices:
> file_inode(filp)->i_mapping =
> bdev->bd_inode->i_mapping;
>
> and this seems like it should work for that. I know about coda:
> coda_inode->i_mapping = host_inode->i_mapping;
>
> and this seems like it should work there too.
>
> DAX just seems confused:
> inode->i_mapping = __dax_inode->i_mapping;
> inode->i_mapping->host = __dax_inode;
> inode->i_mapping->a_ops = &dev_dax_aops;
>
> GFS2 might need to embed an entire minode instead of just a mapping in its
> glocks and its superblock:
> fs/gfs2/glock.c: mapping->host = s->s_bdev->bd_inode;
> fs/gfs2/ops_fstype.c: mapping->host = sb->s_bdev->bd_inode;
I don't think that will scale. We did gain a big reduction in overhead
for each cached inode when we stopped using two struct inodes and just
embedded an address_space in the glock. However, I'm fairly sure that
for the glock address_space case, we already have our own way to find
the associated inode. So it might well be ok to do this anyway, and not
need to embed a full minode.
Also, if there was a better way to track metadata on a per inode basis,
then that would be an even better solution, but a much bigger project too.
The issue that you might run across is for stacked filesystems... will
you land up finding the correct layer in the stack?
Steve.
>
> NILFS ... I don't understand at all. It seems to allocate its own
> private address space in nilfs_inode_info instead of using i_data (why?)
> and also allocate more address spaces for metadata inodes.
> fs/nilfs2/page.c: mapping->host = inode;
>
> So that will need to be understood, but is there a fundamental reason
> this won't work?
>
> Advantages:
> - Eliminates a pointer dereference when moving from mapping to host
> - Shrinks all inodes by one pointer
> - Shrinks inodes used for symlinks, directories, sockets, pipes & char
> devices by an entire struct address_space.
>
> Disadvantages:
> - Churn
> - Seems like it'll grow a few data structures in less common filesystems
> (but may be important for some users)
>
More information about the Cluster-devel
mailing list