>> It's worth reminding that -o tcp is an option.
> Not for NFS through a (stateful) filtering router, no.
True.
But then, not over network hops that drop port 2049, either. Break the
assumptions underlying the 'net and you have to expect breakage from
stuff built atop it.
/~\ The ASCII
At 10:45 Uhr +0200 31.07.2019, Edgar Fuß wrote:
>Thanks to riastradh@, this tuned out to be caused by an (UDP, hard) HFS
>mount combined with a mis-configured IPFilter that blocked all but the
>first fragment of a fragmented NFS reply (e.g., readdir) combined with a
>NetBSD design error (or so
On Wed, Jul 31, 2019 at 07:11:54AM -0700, Jason Thorpe wrote:
>
> > On Jul 31, 2019, at 1:45 AM, Edgar Fuß wrote:
> >
> > NetBSD design error (or so Taylor says) that a vnode lock may be held
> > accross I/O
>
> 100%
>
> NetBSD's VFS locking protocol needs a serious overhaul. At least one
On Wed, Jul 31, 2019 at 11:42:26AM -0500, Don Lee wrote:
> If you go back a few years, you can find a thread where I reported tstile
> lockups on PPC. I don’t remember the details, but it was back in 6.1 as I
> recall. This is not a new problem, and not limited to NFS. I still have a
> similar
If you go back a few years, you can find a thread where I reported tstile
lockups on PPC. I don’t remember the details, but it was back in 6.1 as I
recall. This is not a new problem, and not limited to NFS. I still have a
similar problem with my 7.2 system, usually triggered when I do backups
> On Jul 31, 2019, at 1:45 AM, Edgar Fuß wrote:
>
> NetBSD design error (or so Taylor says) that a vnode lock may be held accross
> I/O
100%
NetBSD's VFS locking protocol needs a serious overhaul. At least one other
BSD-family VFS (the one in XNU) completely eliminated locking of vnodes
Thanks to riastradh@, this tuned out to be caused by an (UDP, hard) HFS mount
combined with a mis-configured IPFilter that blocked all but the first fragment
of a fragmented NFS reply (e.g., readdir) combined with a NetBSD design error
(or so Taylor says) that a vnode lock may be held accross
