On Wed, 2019-08-28 at 09:11 +0200, Pavel Machek wrote: > On Tue 2019-08-27 09:50:14, Greg Kroah-Hartman wrote: > > [ Upstream commit dea1bb35c5f35e0577cfc61f79261d80b8715221 ] > > > > People are reporing seeing fscache errors being reported concerning > > duplicate cookies even in cases where they are not setting up > > fscache > > at all. The rule needs to be that if fscache is not enabled, then > > it > > should have no side effects at all. > > > > To ensure this is the case, we disable fscache completely on all > > superblocks > > for which the 'fsc' mount option was not set. In order to avoid > > issues > > with '-oremount', we also disable the ability to turn fscache on > > via > > remount. > > Actually, the code seems to suggest that you disable the ability to > turn fscache _off_ via remount, too. > > Is that intentional? > Yes. That is intentional. Otherwise we would have to clear all the fscache cookies from the inodes. > Best regards, > Pavel > > > @@ -2239,6 +2239,7 @@ nfs_compare_remount_data(struct nfs_server > > *nfss, > > data->acdirmin != nfss->acdirmin / HZ || > > data->acdirmax != nfss->acdirmax / HZ || > > data->timeo != (10U * nfss->client->cl_timeout->to_initval > > / HZ) || > > + (data->options & NFS_OPTION_FSCACHE) != (nfss->options & > > NFS_OPTION_FSCACHE) || > > data->nfs_server.port != nfss->port || > > data->nfs_server.addrlen != nfss->nfs_client->cl_addrlen || > > !rpc_cmp_addr((struct sockaddr *)&data->nfs_server.address, -- Trond Myklebust CTO, Hammerspace Inc 4300 El Camino Real, Suite 105 Los Altos, CA 94022 www.hammer.space
