I'm currently running 3.4.26 on quite a few machines with no problem (debian 6 userland). On a brand new machine (dual ivy bridge, 256G of ram), exportfs is not able to export nfs filesystems...
Here's the contents of /etc/exports:
/iris 192.168.0.0/255.255.128.0(rw,no_root_squash,no_subtree_check,fsid=0)
When I run exportfs -a in strace:
6701 open("/etc/exports", O_RDONLY) = 3
6701 fstat(3, {st_mode=S_IFREG|0644, st_size=707, ...}) = 0
6701 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9614629000
6701 read(3, "# This file is automatically generated. DO NOT EDIT.\n#\n# This file defines network filesystems exported by master board controller.\n# These filesystems primarily provide a means for booting diskless blades,\n# as well as relaying configuration information "..., 4096) = 707
6701 open("/proc/fs/nfsd/export_features", O_RDONLY) = 4
6701 read(4, "0x17e3f 0xf\n", 50) = 12
6701 lstat("/iris", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
6701 read(3, "", 4096) = 0
6701 read(3, "", 4096) = 0
6701 close(3) = 0
6701 munmap(0x7f9614629000, 4096) = 0
6701 stat("/iris", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
6701 open("/proc/net/rpc/auth.unix.ip/channel", O_WRONLY) = 3
6701 write(3, "nfsd 0.0.0.0 2147483647 -test-client-\n", 38) = 38
6701 close(3) = 0
6701 open("/proc/net/rpc/nfsd.export/channel", O_WRONLY) = 3
6701 close(3) = 0
6701 statfs("/iris", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=7692434, f_bfree=5253463, f_bavail=4862710, f_files=1954064, f_ffree=1808133, f_fsid={1266779845, 50719849}, f_namelen=255, f_frsize=4096}) = 0
6701 open("/proc/net/rpc/nfsd.export/channel", O_WRONLY) = 3
6701 write(3, "-test-client- /iris 3 8192 -1 -1 0\n", 35) = -1 ENOENT (No such file or directory)
6701 close(3) = 0
Looking at some of the kernel code, I found that auth_domain_find in fs/nfsd/export.c around line 514 is returning NULL.
I'm at a complete loss because this exact setup (same kernel exactly, same exports, everything) is working on a separate machine. The only difference is the underlying hardware. My kernel config is attached.
> Looking at some of the kernel code, I found that auth_domain_find in
> fs/nfsd/export.c around line 514 is returning NULL.
I added code some printks to auth_domain_lookup() in net/sunrpc/svcauth.c to printk every time loop of hlist_for_each_entry and it's not printing anything so it doesn't look like the write to /proc/net/rpc/auth.unix.ip/channel by exportfs is having any effect. My off the wall guess is that it's related to NUMA somehow, but I have no way to validate this idea. Besides, I feel like many other things would be broken if NUMA wasn't working correctly.
> I'm at a complete loss because this exact setup (same kernel exactly, same
> exports, everything) is working on a separate machine. The only difference is
> the underlying hardware. My kernel config is attached.
Is there anything else I can add? Only thing I can think of that I left out is that this is an ext3 filesystem.
On Thu, Apr 18, 2013 at 03:40:05PM +0000, Stoltenberg, Matthew wrote:
> > Looking at some of the kernel code, I found that auth_domain_find in
> > fs/nfsd/export.c around line 514 is returning NULL.
>
> I added code some printks to auth_domain_lookup() in net/sunrpc/svcauth.c to printk every time loop of hlist_for_each_entry and it's not printing anything so it doesn't look like the write to /proc/net/rpc/auth.unix.ip/channel by exportfs is having any effect. My off the wall guess is that it's related to NUMA somehow, but I have no way to validate this idea. Besides, I feel like many other things would be broken if NUMA wasn't working correctly.
>
> > I'm at a complete loss because this exact setup (same kernel exactly, same
> > exports, everything) is working on a separate machine. The only difference is
> > the underlying hardware. My kernel config is attached.
>
> Is there anything else I can add? Only thing I can think of that I left out is that this is an ext3 filesystem.
Huh, that is weird. Your strace basically shows "-test-client-"
succesfully added to the audh_domain table and then the immediately
following call not finding it there any more.
All I can think is that perhaps the expiry (read and caclculated by the
get_expiry() call in net/sunrpc/svcauth_unix.c:ip_map_parse()) is bogus,
resulting in ip_map_parse()'s final cache_flush immediately evicting the
new entry.
And I guess a boot-time related problem could be hardware dependent
somehow.
--b.