Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Jul 2015 19:36:16 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Ahmed Kamal <email.ahmedkamal@googlemail.com>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Linux NFSv4 clients are getting (bad sequence-id error!)
Message-ID:  <684628776.2772174.1435793776748.JavaMail.zimbra@uoguelph.ca>
In-Reply-To: <CANzjMX45QaC8yZx2nHPAohJRvQjmUOHuhMQWP9nX%2BsrJs707Hg@mail.gmail.com>
References:  <CANzjMX45QaC8yZx2nHPAohJRvQjmUOHuhMQWP9nX%2BsrJs707Hg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Ahmed Kamal wrote:
> Hi all,
> 
> I'm a refugee from linux land. I just set up my first freebsd 10.1 zfs box,
> sharing /home over nfs. Since every home directory is its own zfs dataset,
> I chose to use nfsv4 to enable recursively sharing/mounting any directory
> under /home (I understand nfs4 is a must in this scenario!)
> 
> I'm able to mount form linux (rhel5 latest kernel) successfully. Users are
> working fine. However every now and then a user screams that his session is
> frozen. Usually the processes are stuck in nfs_wait or rpc_* state. I tried
> using a much newer linux kernel (3.2 however it still faced the same
> problem). The errors in Linux log files are mostly:
> Jul  1 17:41:47 mammoth kernel: NFS: v4 server nas  returned a *bad
> sequence-id error*!
> Jul  1 17:52:32 mammoth kernel: nfs4_reclaim_locks: unhandled error -11.
> Zeroing state
> Jul  1 17:52:32 mammoth kernel: nfs4_reclaim_open_state: Lock reclaim
> failed!
> 
Btw, a client should only do "reclaim" operations after the server has
replied with NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID. I am pretty
certain that the FreeBSD NFSv4 server only generates these replies after
it has rebooted, so assuming the server didn't reboot, I have no idea why
the client would attempt these and am not surprised they failed.

I'm guessing that the DRC constipation somehow caused the Linux client
to go into recovery mode?

rick

> My search led me to (https://access.redhat.com/solutions/1328073) a
> detailed analysis of the issue, which you can read over here
> https://dl.dropboxusercontent.com/u/51939288/nfs4-bad-seq.pdf .. NetApp
> confirmed this was a bug for them (I'm wondering if this is still in
> FreeBSD?!)
> 
> PS: Right before sending this, I saw dmesg on the freebsd box advising
> increasing vfs.nfsd.tcphighwater .. So I up'ed that to 64000. I also up'ed
> the number of nfs server threads (-t) from 10 to 60 (we're roughly 40 linux
> machines)
> 
> Any advice is most appreciated!
> 
> Thanks
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?684628776.2772174.1435793776748.JavaMail.zimbra>