On Wed, 2018-07-11 at 12:24 -0400, Scott Mayhew wrote:
> On Wed, 11 Jul 2018, Benjamin Coddington wrote:
>
> > So there's two changes here, the first is that we don't call
> > nfs_fscache_get_client_cookie() if rpc_ops->init_client fails,
> > which makes
> > sense. The second is that we create separate fscache indexes for
> > minor
> > versions. Why do we need separate caches if the nfs_client is the
> > same? I
> > thought that the nfs_client is just there to have something to hang
> > the
> > superblock caches from..
> >
> > Is the problem that we can take down one nfs_client and then
> > initialize a
> > new one, but the nfs_server_key is exactly the same, so now we
> > start to add
> > new objects before fscache has cleaned up old references?
>
> The nfs_clients aren't the same, and nothing's being torn down.
>
> I'm using steved's "runcthon" script from cthon which performs
> multiple cthon runs simultaneiously. I have different superblocks,
> nfs_servers, nfs_clients, and fscache_cookies. But the keys for the
> v4.x mounts are all the same. David indicated that was problematic,
> so
> I suggested adding the minor version to the key, which he said was
> fine.
So what is the use case for having a NFSv4 and NFSv4.1 mount of the
same filesystem? I agree we shouldn't crash, but I'm lost as to why
someone would want to do this.
IOW: Why isn't the right thing to do here just to remove the bogus
BUG_ON()?
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
