From owner-freebsd-net@freebsd.org Wed Aug 3 00:26:37 2016 Return-Path: <owner-freebsd-net@freebsd.org> Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 560FFBADF04 for <freebsd-net@mailman.ysv.freebsd.org>; Wed, 3 Aug 2016 00:26:37 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B4BF1695; Wed, 3 Aug 2016 00:26:37 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from <slw@zxy.spb.ru>) id 1bUk12-000CCe-Qg; Wed, 03 Aug 2016 03:26:32 +0300 Date: Wed, 3 Aug 2016 03:26:32 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Rick Macklem <rmacklem@uoguelph.ca>, trasz@FreeBSD.org Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Is NFSv4 mount interruptible? Message-ID: <20160803002632.GP8192@zxy.spb.ru> References: <20160802223728.GN8192@zxy.spb.ru> <YTXPR01MB049518E305D351F36900774FDD050@YTXPR01MB0495.CANPRD01.PROD.OUTLOOK.COM> <20160802225502.GO8192@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160802225502.GO8192@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: <locally generated> X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 03 Aug 2016 00:26:37 -0000 On Wed, Aug 03, 2016 at 01:55:02AM +0300, Slawa Olhovchenkov wrote: > On Tue, Aug 02, 2016 at 10:48:52PM +0000, Rick Macklem wrote: > > > Slawa wrote: > > >I have autofs NFSv4 mount with /etc/nfs.map: > > > > > >/NFS -nfsv4,intr,soft,sec=krb5i,gssname=host storage01:/ > > > > > >Currently I am see NFS hung and I am can't kill shell and can't > > >unmount /NFS. > > > > > >Is NFSv4 mount interruptible? > > >Or intr support only by NFSv3? > > Well, in the BUGS section of "man mount_nfs" it notes that soft and intr cannot be > > safely used with NFSv4. The problem is that, if an RPC that updates state (Open, Close,...) > > terminates, then the state is no longer usable. > > > > You can "umount -f" the file system, but only if no other "umount" is already in progress. > > (I am working on a new umount option that will allow "umount -f" to succeed when another > > umount is stuck. It requires "umount(8)" to avoid all the path checking, etc.) > > > > Personally, I would never use "soft" for any mount (except read-only maybe), since it can > > result in a write failure when the NFS server is slow. Using "intr" should be ok for NFSv3, > > since it is stateless. > > For me, this mount like r/o. > I am don't have significant write to this mount. > If some data lost I am able to create this data again. > Currently NFS hang after long idle. > > I am try to do umount, w/o success: > > # ps -ax | grep mou > 706 - Is 0:00.00 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid > 1116 - Ds 1:16.50 /usr/sbin/autounmountd > 86794 3- T+ 0:00.00 umount -f /NFS > > # procstat 86794 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 86794 86791 86794 86788 86788 1 admin autofsvl FreeBSD ELF64 umount > > # procstat 1116 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 1116 1 1116 1116 0 1 root newnfs FreeBSD ELF64 autounmountd > May be this is autofs issuse? Can be autofsvlk lock leaks? # procstat -a | grep autofsvl 23767 23759 23757 23738 0 1 root autofsvl FreeBSD ELF64 find 27588 1067 27588 27588 0 1 root autofsvl FreeBSD ELF64 sshd 27722 1067 27722 27722 0 1 root autofsvl FreeBSD ELF64 sshd 28520 28519 28520 28513 28513 1 admin autofsvl FreeBSD ELF64 csh 44829 44825 44717 44717 0 1 root autofsvl FreeBSD ELF64 find 86577 1067 86577 86577 0 1 root autofsvl FreeBSD ELF64 sshd 86588 86587 86588 86582 86582 1 admin autofsvl FreeBSD ELF64 csh 86794 86791 86794 86788 86788 1 admin autofsvl FreeBSD ELF64 umount # procstat -k 23767 27588 27722 28520 44829 86577 86588 86794 PID TID COMM TDNAME KSTACK 23767 101917 find - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei kern_statat_vnhook sys_fstatat amd64_syscall Xfast_syscall 27588 102087 sshd - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei vn_open_cred kern_openat amd64_syscall Xfast_syscall 27722 101649 sshd - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei vn_open_cred kern_openat amd64_syscall Xfast_syscall 28520 101961 csh - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei kern_statat_vnhook sys_stat amd64_syscall Xfast_syscall 44829 102258 find - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei kern_statat_vnhook sys_fstatat amd64_syscall Xfast_syscall 86577 101721 sshd - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei vn_open_cred kern_openat amd64_syscall Xfast_syscall 86588 101765 csh - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei kern_statat_vnhook sys_stat amd64_syscall Xfast_syscall 86794 101690 umount - mi_switch sleepq_wait _sx_xlock_hard _sx_xlock autofs_node_vn lookup namei kern_statfs sys_statfs amd64_syscall Xfast_syscall