(net-fs/nfs-utils-1.2.3-r1, Gentoo)

Googling this seems to be a complete dead end. man nfsstat says a whole lot of nothing about the subject. The closest I could get was finding out about what was probably previously "newcreds".

newcreds Number of times authentication information had to be refreshed.

My problem is that I think I'm seeing subpar NFS performance over OpenVPN and the only thing I can immediately see that is significantly different than all nfsstat Google results, is that my "calls" field equals exactly "authrefrsh" and is therefore very high. All the search result outputs always had authrefrsh as 0 or a very low number. Before I can move on to debugging some other aspects, I could use finding out what this means.

Watched operation is emerging a package over NFS-shared portage. emerge does traverse a big tree during it's operation but previous experience says the performance I'm seeing is abnormal.

$ watch -n 1 nfsstat -c

Every 1,0s: nfsstat -c                                Sat May 21 23:04:55 2011

Client rpc stats:
calls      retrans    authrefrsh
308565     2211       308565

Client nfs v3:
null         getattr      setattr      lookup       access       readlink
0         0% 172372   55% 17        0% 30485     9% 36057    11% 26831     8%
read         write        create       mkdir        symlink      mknod
25879     8% 107       0% 21        0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
16        0% 0         0% 11        0% 0         0% 0         0% 16668     5%
fsstat       fsinfo       pathconf     commit
3         0% 50        0% 25        0% 2         0%

I can't figure out exactly what authrefrsh is (and this spelling, is that intentional btw?) and why is it increasing like this in my case?

  • When you say slow NFS, what leads you to believe that the NFS performance should be faster? Can you quantify slow? Does time of day matter WRT performance?
    – This
    May 24 '11 at 11:07
  • "Slow NFS" means that NFS traffic should have no trouble taking up whole bandwidth available, which over VPN wasn't that much (100 kB/sec). Instead iftop was showing me traffic of only single digit kB/sec over tun0. I believe I have narrowed the problem down to Portage stat'ing a couple of thousand packages in my PKGDIR during binpkg related emerge runs, which seems to be excruciatingly slow operation. From what I can tell so far, the best solution might be having regularly updated squashfs portage on the remote workstations and getting binpkgs over HTTP binhost, instead of NFS-mounted PKGDIR.
    – lkraav
    Jun 5 '11 at 0:42
  • Any updates on this? I've noticed poorer NFS client performance with newer SLES 11 and CentOS 6 servers when compared to our older SLES 9 servers. SLES 9 clients are speedier, and also show authrefrsh=0, while the newer OS' show a ton of authrefrsh. I think there is a correlation here, but not quite sure what this all means.
    – Banjer
    May 5 '13 at 15:55
  • What type of NFS authentication are you doing? AUTH_SYS?
    – Bratchley
    May 7 '13 at 15:13
  • To answer part of your question though, authrefrsh is the number of times the NFS client has called call_refresh() which is basically going out to the RPC server (portmap, rpcbind, etc) and validating its credentials with the server. We need to figure out if it's actually what's causing the latency. If you're doing AUTH_SYS then the overhead is low and wouldn't be the cause.
    – Bratchley
    May 7 '13 at 15:16

From the Red Hat article in the comments the solution says

This is expected behaviour.

Not very helpful but it also points out the reason it happens.

It references commit a17c2153d2e271b0cbacae9bed83b0eaa41db7e1 in the sunrpc package that moves where nfs authentication takes place. I won't copy/paste the entire commit but it mostly changes these lines.

-struct rpc_cred *cred = task->tk_msg.rpc_cred;
+struct rpc_cred *cred = task->tk_rqstp->rq_cred;

My limited understanding is that this line moves where the call_refresh() happens (sooner rather than later). This in turn means most all nfs requests will cause authrefrsh to increment as authentication is always used.


I'm seeing the same thing (not using vpn) - authrefrsh == calls on the client side. It seems to me like the number of calls increases, then slows down, and the number of authrefrsh then catches up.

Client rpc stats:

calls      retrans    authrefrsh
261697     0          261697

I see very high iowait too:

dd if=/dev/zero of=/mnt/omoikane/testfile bs=16k count=2048

(from iostat:)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          4.04    0.00    4.04   91.92    0.00    0.00

I can't see anything unusual in wireshark - I'm using nfs3 and tcp.


From what I understand from this link, authrefresh = calls isn't indicating a problem.


  • Welcome to Unix & Linux! Generally we like answers on the site to be able to stand on their own - Links are great, but if that link ever breaks the answer should have enough information to still be helpful. Please consider editing your answer to include more detail. See the FAQ for more info.
    – slm
    Apr 15 '13 at 18:22
  • what they mean is they're not sure it's the cause of the problem or just going up due to it. "skyrocketing" is definitely indicating things aren't fine. similarly this is mostly seen in parallel with ugly perf issues. May 19 '16 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.