[Gluster-devel] [RFC] various lists on inode table usage?

Amar Tumballi amarts at gmail.com
Mon Oct 21 07:40:45 UTC 2019


On Mon, Oct 21, 2019 at 1:02 PM Changwei Ge <chge at linux.alibaba.com> wrote:

> Hi Amar,
>
> Thank you very much for your quick reply :-)
>
> On 2019/10/21 2:44 下午, Amar Tumballi wrote:
> >
> >
> > On Mon, Oct 21, 2019 at 11:58 AM Changwei Ge <chge at linux.alibaba.com
> > <mailto:chge at linux.alibaba.com>> wrote:
> >
> >     Hi,
> >
> >     I am recently working on optimizing inode searching/getting/putting
> >     concurrency. Before the experiment/trial goes, I would like to get
> >     fully
> >     understand what the usage of several lists of inode table, especially
> >     for 'invalidate list', since the major difficulty making inode
> >     searching
> >     run concurrently is that We have to move inode from one list to the
> >     other and modify some attributes against inode table.
> >     After reading corresponding code, it seems that inode table
> 'invalidate
> >     list' is only retrieved when destroying inode
> >     table(inode_table_destroy).
> >
> >     Can someone help explain the list usage/purpose of 'invalidate list'?
> >
> >
> > 'invalidate_list' is used only in client side. The patch which got it is
> > below:
> >
> >
> https://github.com/gluster/glusterfs/commit/d49b41e817d592c1904b6f01716df6546dad3ebe
> >
> >
> > Hope this gives some idea.
>
> Cool, this helps me to understand more deeply on inode table.
> I will check out other related commits as well.
>
> >
> > Happy to help. If there is an interest, we can even have a video
> > conference for all interested developers to discuss inode table, and
> > detail out how it is done.
> >
>
> Ack.
> As I think that inode table(how we manage inode/dentry) is one of the
> most critical parts of a certain type of FS, we should consider and
> design carefully hence run it efficiently.
> What I can see from glusterfs HEAD code is that we might have many
> locking contentions and burden too much logic into inode_[un]ref().
>

This is true. And I tried couple of approaches. Couldn't get to take it to
completion earlier.

* https://review.gluster.org/22242
* https://review.gluster.org/22243
* https://review.gluster.org/22186
* https://review.gluster.org/22156

* https://github.com/gluster/glusterfs/issues/204



>
> So how can we arrange a video conference and have a further discussion?
>
>
Open for suggestions. We have weekly Community meeting, which can be
extended to talk about this.


> Thanks,
> Changwei
>
> > For getting complete history of changes to inode.c (from
> >
> https://github.com/amarts/glusterfs/commit/72db44413ce4686b465c29ea8383fa4f09f53a76),
>
> > you can clone github.com/amarts/glusterfs
> > <http://github.com/amarts/glusterfs> and see that over time what
> changes
> > got into the file... 'git log libglusterfs/src/inode.c' gives an idea.
> >
> > Regards,
> > Amar
> >
> >
> >
> >     Thanks,
> >     Changwei
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20191021/6fe81334/attachment.html>


More information about the Gluster-devel mailing list