Date: Fri, 27 Jan 2012 11:33:39 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, Rick Macklem <rmacklem@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient Message-ID: <1072010695.266929.1327682019937.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120127195645.G1604@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> On Thu, 26 Jan 2012, Rick Macklem wrote:
>
> > Bruce Evans wrote:
> >
> >> Doesn't umount -f have to wait for i/o anyway? When it closes
> >> files,
> >> it must wait for all in-progress i/o for the files, and for all new
> >> i/o's that result from closing.
> >>
> > umount -f kills off RPCs in progress. There was an email discussion
> > about this, where it seemed there was no advantage in defining a
> > separate "hard forced dismount" for this case.
>
> But umount -f means to close the files, not to lose their contents.
> nfs umount should give a best effort not to lose any contents by
> waiting
> a bit. Maybe it already does. I saw some of the discussion.
>
Well, maybe in theory, but in practice, I don't think it makes much
difference. I can think of 2 scenarios where a sysadmin might use
"umount -f" on an NFS mount point:
1 - The NFS server is unresponsive (crashed or network partitioned)
and the sysadmin can't wait until it comes back online.
--> waiting a fraction of a second won't have any effect on the
outcome unless the server comes back online within that fraction
of a second. Since the sysadmin isn't willing to wait...
2 - The sysadmin needs to unmount the file system now, but some program
has file(s) open on the mount point, so a normal unmount fails
with EBUSY.
--> Any programs with file(s) open for writing on the mount, will
have those opens arbitrarily closed and subsequent write attempts
will fail. As such, the programs won't be able to get the data
written. (Yes, you could argue that the program was just finishing
doing any writing it wanted to do and waiting a fraction of a
second would allow it to complete, but that's basically the same
argument as for #1.) No different than the sysadmin waiting a
fraction of a second longer before they type "umount -f /mnt"
from what I see.
rick
> BTW, I just replied to the POSIX list about close() returning EINTR.
> POSIX has the silly specification that close() shall not discard any
> ouput for a terminal device file [although an endless wait may be
> required for that] but no similar detail for much more important types
> of files. unmount() is better behaved than close() here since it can
> and does actually handle cached data correctly by failing when there
> is an i/o error writing it.
>
> Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1072010695.266929.1327682019937.JavaMail.root>