On Tue, 2012-02-07 at 14:12 -0500, Jeff Layton wrote: > 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. Wait. How is that true? The whole point of this patchset is that it allows you to compile in support for _both_ idmappers, with the new keyring-based idmapper being tried first. The client then falls back to using the old idmapper if and only if the user has failed to set up the new idmapper correctly. > 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. I'd like to see the old idmapper code changed to use the new keyring-based cache instead. I've asked Bryan to look into how we can do this. -- 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�����٥
