> On Oct 17, 2014, at 4:06 PM, Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> wrote: > > On Fri, 17 Oct 2014 09:42:14 -0500 > Colin Hudler <chudler@xxxxxxxxxxxxxxx> wrote: > >> We have a few hundred computers mounting an NFS server in a typical >> LDAP-based users (nss) setup. We frequently add and remove exports and >> use exportfs -r to update etab. Every time we do so, the clients report >> "NFS server not responding" and start backing off their requests. After >> a painful 3-5 minutes, they recover and life is normal again. >> >> We discovered that when the rpc.mountd cache flushing occurs, our NIS >> system is overwhelmed with grouplist requests and this obviously blocks >> things. We are working on that problem separately, and I admit this to >> be a weakness in our setup. My question is simple. >> >> Why does it flush auth.unix.gid when the etab changed? I think it makes >> unnecessary work for rpc.mountd because the gids are unlikely to have >> changed, and they already have a reasonable expiration policy. > > Most likely because no one really cared until now. > > When exports change, cache_flush() is called and that function flushes > out all of the kernel caches. > > I expect that could be made to do something a bit more granular, but > you may need to do some archaeology in mountd/exportfs (and the kernel) > to ensure that you're not missing anything. > One thing would be to not remove the exports which are going to be added back in. The catch here is that you have to account for new entries which need to be added. > -- > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
