Date: Fri, 27 Jan 2012 20:18:19 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: svn-src-head@FreeBSD.org, Rick Macklem <rmacklem@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient Message-ID: <20120127195645.G1604@besplex.bde.org> In-Reply-To: <1513888354.186214.1327592563003.JavaMail.root@erie.cs.uoguelph.ca> References: <1513888354.186214.1327592563003.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120127195645.G1604>