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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1105301921460.1535>