Skip site navigation (1)Skip section navigation (2)
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>