Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jan 2012 10:56:54 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Jaakko Heinonen <jh@FreeBSD.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: should mount -u fail or silently ignore options?
Message-ID:  <219911446.737753.1327334214785.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <20120123153833.GB2246@a91-153-116-96.elisa-laajakaista.fi>

next in thread | previous in thread | raw e-mail | index | archive | help
Jaakko Heinonen wrote:
> On 2012-01-22, Rick Macklem wrote:
> > There is a bug in the NFS clients, where a
> > "mount -u -o udp /mnt" will cause any threads
> > that have an RPC in progress to hang, if the
> > mount previously was using too large an rsize/wsize.
> 
> Does the hang occur if the UDP transport was already used?
> 
I don't think so. I did test the case where it switched from
TCP to UDP, but the TCP mount had rsize=16384,wsize=16384 and
that was fine. The problem occurs when the rsize/wsize for the
mount is > 16K before the change to UDP (which "can't" be the
case if the mount is already UDP).

The patch only generates an error if the old rsize/wsize is
greater than 16K. Or, it could be easily re-written to silently
ignore the request to switch to UDP.

> > This case can easily be detected in nfs_mount().
> >
> > However, my question is...
> > - Should the "mount -u" fail and return an error
> > OR
> >   Silently ignore the "udp" option and return ok.
> 
> Depending on the answer to the question above, IMHO the best solution
> would be to return an error if user tries to change TCP to UDP but
> accept the "udp" option if UDP transport is already active. I don't
> know
> about potential problems with root nfs.
> 
Yea, I feel returning an error makes more sense than silently ignoring
the request. The concerns I had were related to diskless roots.

Thanks for the comments, rick

> --
> Jaakko



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?219911446.737753.1327334214785.JavaMail.root>