On Thu, 26 Jan 2012 16:54:23 -0500
bjschuma@xxxxxxxxxx wrote:
> From: Bryan Schumaker <bjschuma@xxxxxxxxxx>
>
> This patch removes the CONFIG_NFS_USE_NEW_IDMAPPER compile option.
> First, the idmapper will attempt to map the id using /sbin/request-key
> and nfsidmap. If this fails (if /etc/request-key.conf is not configured
> properly) then the idmapper will call the legacy code to perform the
> mapping. I left a comment stating where the legacy code begins to make
> it easier for somebody to remove in the future.
>
> Signed-off-by: Bryan Schumaker <bjschuma@xxxxxxxxxx>
> ---
I think this patch is the right approach and will make the transition
easier. But there is still a bit of a problem here...
One of the main complaints about the old idmapper was that it did a
rather large allocation on every time a new nfs_client is created:
-----------------------[snip]----------------------
int
nfs_idmap_new(struct nfs_client *clp)
{
struct idmap *idmap;
struct rpc_pipe *pipe;
int error;
BUG_ON(clp->cl_idmap != NULL);
idmap = kzalloc(sizeof(*idmap), GFP_KERNEL);
if (idmap == NULL)
return -ENOMEM;
-----------------------[snip]----------------------
On a 32-bit box when you try to mount and low memory is heavily
fragmented, you can get a NULL pointer back on that kzalloc with a
nice stack trace headed by a message like this:
mount.nfs: page allocation failure. order:4, mode:0xc0d0
Here's a RHBZ against RHEL6 if you're interested in gory details:
https://bugzilla.redhat.com/show_bug.cgi?id=730045
In any case, this problem was one of the reasons for pushing the new
idmapper. A number of people have complained about this problem in the
past and we told them "use the new idmapper". Now, with this patchset,
that won't help.
I think the right solution is to probably look at breaking up the idmap
structure in the legacy idmapper into multiple allocations. It's more
complicated to deal with and will mean restructuring the code a bit,
but it will allow for a relatively graceful transition to the new
idmapper.
Thoughts?
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
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
