svn commit: r230516 - in head/sys: fs/nfsclient nfsclient

[Bruce Evans]

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.

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