Date: Mon, 30 May 2011 19:22:55 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, Rick Macklem <rmacklem@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222466 - head/sbin/umount Message-ID: <alpine.BSF.2.00.1105301921460.1535@fledge.watson.org> In-Reply-To: <20110530130751.GV48734@deviant.kiev.zoral.com.ua> References: <201105292113.p4TLDrA3046886@svn.freebsd.org> <alpine.BSF.2.00.1105301347380.60306@fledge.watson.org> <20110530130751.GV48734@deviant.kiev.zoral.com.ua>
index | next in thread | previous in thread | raw e-mail
On Mon, 30 May 2011, Kostik Belousov wrote: > On Mon, May 30, 2011 at 01:48:53PM +0100, Robert Watson wrote: >> On Sun, 29 May 2011, Rick Macklem wrote: >> >>> Modify the umount(8) command so that it doesn't do a sync(2) syscall >>> before unmount(2) for the "-f" case. This avoids a forced dismount from >>> getting stuck for an NFS mountpoint in sync() when the server is not >>> responsive. With this commit, forced dismounts should normally work for >>> the NFS clients, but can take up to about 1minute to complete. >> >> I'm actually a bit confused about why umount(8) calls sync(2) at all: >> surely it's the responsibility of the file system, rather than the userland >> tool, to ensure consistency subject to file system configuration and >> unmount-time flags? > This call is from the same department as triple-sync before reboot, IMO. No doubt. :-) If the sync(2) has actual consistency and reliability benefits, it should probably be done by the umount(2) system call, so that other future auto-mounters, etc, also get the same result, rather than having to encode it in every application. If it's done on blind faith, perhaps it shouldn't be done at all. Roberthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1105301921460.1535>