Date: Fri, 31 May 2024 13:11:20 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: J David <j.david.lists@gmail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: NFSv4 hangs on 13.3 Message-ID: <CAM5tNy7YSTDwVm_oMcu=1PqRyXtTmvzTF058nd1WCXyCHwrtTQ@mail.gmail.com> In-Reply-To: <CABXB=RTH6s25EMQzDbg8WPr1hKtjKOJGVh3no0TFcNC=ufwXCw@mail.gmail.com> References: <CABXB=RTH6s25EMQzDbg8WPr1hKtjKOJGVh3no0TFcNC=ufwXCw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 31, 2024 at 12:39=E2=80=AFPM J David <j.david.lists@gmail.com> = wrote: > > In an attempt to narrow down the problems we have with NFS v4.2, we've > set up a FreeBSD 13.3 server that mirrors some read-only data from our > Linux NFS servers. > > We are still observing occasional hangs on the FreeBSD 13.3 client machin= es. > > When these hangs occur, anything that touches the mountpoint > (including "umount -N") hangs indefinitely. There is nothing in dmesg. > > The only even slightly informative data I could gather is an "ls > /mount/point" kstack: > > $ sudo procstat -kk 94676 > PID TID COMM TDNAME KSTACK > 94676 976876 ls - mi_switch+0xbf > sleeplk+0xea lockmgr_slock_hard+0x3a5 nfs_lock+0x29 vop_sigdefer+0x2a > _vn_lock+0x47 vfs_cache_root+0x9d vfs_root_sigdefer+0x35 lookup+0x88a > namei+0x24a kern_statat+0xf8 sys_fstatat+0x27 amd64_syscall+0x110 > fast_syscall_common+0xf8 > > During this time, the NFS server continues serving other clients, and > the affected client can access other NFS servers without hanging. > > The "nfsstat -m" for this mountpoint looks like this: > > nfsv4,minorversion=3D2,oneopenown,tcp,resvport,nconnect=3D1,hard,cto,nolo= ckd,sec=3Dsys,acdirmin=3D3,acdirmax=3D60,acregmin=3D5,acregmax=3D60,nametim= eo=3D60,negnametimeo=3D60,rsize=3D65536,wsize=3D65536,readdirsize=3D65536,r= eadahead=3D1,wcommitsize=3D16777216,timeout=3D120,retrans=3D2147483647 > > with these mount flags in /etc/fstab: > > ro,nfsv4,minorversion=3D2,tcp,nosuid,noatime,nolockd,oneopenown > > Is there anything more we can do to help identify this issue? Collect the output of: # ps axHl and # procstat -kk -a What you show above is just a thread waiting for a lock on an NFS vnode. What we need to figure out is what thread is holding the lock on that vnode while waiting for something else. rick > > Thanks for any advice! >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7YSTDwVm_oMcu=1PqRyXtTmvzTF058nd1WCXyCHwrtTQ>