[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170524174000.GC13151@infradead.org>
Date: Wed, 24 May 2017 10:40:00 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Shaohua Li <shli@...com>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, tj@...nel.org,
gregkh@...uxfoundation.org, viro@...iv.linux.org.uk,
Kernel-team@...com
Subject: Re: [PATCH 1/5] kernfs: implement i_generation
On Tue, May 23, 2017 at 08:09:48AM -0700, Shaohua Li wrote:
> > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> > > index db5900aaa..09d093e 100644
> > > --- a/fs/kernfs/dir.c
> > > +++ b/fs/kernfs/dir.c
> > > @@ -634,6 +634,7 @@ static struct kernfs_node *__kernfs_new_node(struct kernfs_root *root,
> > > if (ret < 0)
> > > goto err_out2;
> > > kn->ino = ret;
> > > + kn->generation = atomic_inc_return(&root->next_generation);
> >
> > i_generation is only supposed to be valid on a per-inode basis, so this
> > global counter seems really odd.
>
> What's the difference between per-inode or per-super? The i_generation doesn't
> need to be consecutive for an inode. I checked other fs, a lot of filesystems
> implement i_generation in this way, for example, f2fs, ext4.
of course per-sb is a valid implementation, but it seems like
introducing an easily avoidable bottleneck by serializing on a per-sb
cacheline for each file creation. But then again it seems like kernfs
already has various other per-sb contention points, so maybe it's not
an issue in the end.
Powered by blists - more mailing lists