On Mon, 2012-06-18 at 11:04 +0200, Andre Tomt wrote:
> On 16. juni 2012 21:59, Myklebust, Trond wrote:
> > It looks to me as if the legacy upcall code is assuming that there can
> > be no more than 1 upcall at a time: there is only a single
> > idmap->idmap_key_cons, which gets assigned in nfs_idmap_legacy_upcall
> > and then read in idmap_pipe_downcall.
> >
> > Bryan, can you look into this? I suspect that we need a mutex or
> > something like that (for the legacy upcall case only) to ensure that
> > nobody overwrites the idmap->idmap_key_cons while an upcall is in
> > progress.
> >
> > Andre, if you want idmapper scalability, then you should rather use the
> > new idmapper upcall. You need a recent version of the nfs-utils package,
> > the keyutils package, and they you should add an 'id_resolver' line
> > to /etc/request-keys.conf as per the nfsidmap manpage.
>
> Indeed, using keyutils did avoid the crashes here, 40 hours and counting.
>
> Are there any downsides of having keyutils w/ id_resolver on by default
> in a distribution? Would it break older kernels or nfs-utils (just not
> getting used is fine, obviously)?
Older kernels aren't able to use the keyutils mechanism, so they will
still require you to run the idmapd daemon, but there should be no
problems with just enabling it in /etc/request-key.conf.
Fedora 17 is supposed to install the id_resolver by default.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
