Re: VOP_PUTPAGE ignores mount_nfs -o soft,intr

[christos%astron.com@localhost (Christos Zoulas)]

In article <20150619215901.GA22894%netbsd.org@localhost>,
David Holland  <dholland-tech%netbsd.org@localhost> wrote:
>On Fri, Jun 19, 2015 at 05:42:45PM +0000, Christos Zoulas wrote:
> > >This cv_wait() is tiemout-less and uninterruptible. ioflush will 
> > >sleep there forever, holding vnode lock. Any other process doing
> > >I/O on the filesystem will sleep in tstile waiting for the vnode
> > >lock with this path: 
> > >sys_write / dofilewrite / vn_write / vn_lock / VOP_LOCK / rw_enter
> > 
> > Yes, but ioflush is not a user process... An interruptible mount
> > means that a user process can interrupt a syscall doing an NFS
> > operation. No other operating system I know of, takes this to mean
> > that you can unmount the filesystem or make delayed writes abort
> > and fail.
>
>Sure. But it also doesn't mean that there should be cases where I/O to
>the filesystem hangs uninterruptibly.
>
>Nothing is supposed to hang in tstile; therefore, this wait is
>incorrect...

Ok, what is it supposed to do? Does it fail? Give up? Get interrupted
and keep looping?

> > Having said that, yes it is a problem that you need to reboot
> > because an NFS server is gone, and we should make umount -f work
> > properly in that case. I don't think that we should introduce umount
> > -l (like linux) unless there is a compelling reason to do so.
>
>I would say we want umount -l, but it's both not trivial and not a
>solution to this problem.

My understanding that umount -l hides the mount, but does not deallocate
resources it can't. So it does not look that hard to me.

christos