>> 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 19:14 Uhr + 31.07.2019, m...@netbsd.org wrote:
>It's worth reminding that -o tcp is an option.
Not for NFS through a (stateful) filtering router, no. Reboot the router,
and you will have to walk up to every client and reboot it. With NFS over
UDP, the clients will recover.
Cheerio,
hauke
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 Tayl
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 ot
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 p
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 at
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 I/