info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is NFSv4 mount interruptible?
10 views
Skip to first unread message
Slawa Olhovchenkov
Aug 2, 2016, 6:37:53 PM8/2/16
to
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?
_______________________________________________
freeb...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
/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?
_______________________________________________
freeb...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
Slawa Olhovchenkov
Aug 2, 2016, 6:55:22 PM8/2/16
to
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
> 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?
> 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
Rick Macklem
Aug 2, 2016, 7:03:38 PM8/2/16
to
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.
rick
>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.
>_______________________________________________
>freeb...@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-net<https://lists.freebsd.org/mailman/listinfo/freebsd-net>
Slawa Olhovchenkov
Aug 2, 2016, 8:26:52 PM8/2/16
to
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:
>
> 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.
>
> > >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?
> 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
>
# 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
0 new messages