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)?
--
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
