From owner-freebsd-fs@FreeBSD.ORG Mon Dec 8 20:29:13 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05DE4B82 for ; Mon, 8 Dec 2014 20:29:13 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98D0CBB7 for ; Mon, 8 Dec 2014 20:29:12 +0000 (UTC) X-AuditID: 1209190c-f79e46d000000eb2-9d-54860a11fb4f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id F5.E7.03762.11A06845; Mon, 8 Dec 2014 15:29:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sB8KT4ni008509; Mon, 8 Dec 2014 15:29:04 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB8KT2Fc017082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Dec 2014 15:29:04 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB8KT2fi004161; Mon, 8 Dec 2014 15:29:02 -0500 (EST) Date: Mon, 8 Dec 2014 15:29:02 -0500 (EST) From: Benjamin Kaduk To: Konstantin Belousov Subject: Re: VFS_SYNC() call in dounmount() In-Reply-To: <20141208181906.GW97072@kib.kiev.ua> Message-ID: References: <20141208181906.GW97072@kib.kiev.ua> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrivI1RZiMHUjt8XhJy4WDdMeszkw ecz4NJ/FY+esu+wBTFFcNimpOZllqUX6dglcGXun72QpuMtf8aXtFXMD4zWeLkZODgkBE4md H+4zQthiEhfurWfrYuTiEBJYzCSx8sN5KGcDo8SNaw+YIJyDTBITJ8xnBmkREqiXaN/8lgXE ZhHQkpjzsRssziagIjHzzUY2EFtEQFfi44I9YHFmASGJg8+/g60TFtCWODf7NVgNp4ChxNmf U9m7GDk4eAUcJe7tsYIYbyDRee83O4gtKqAjsXr/FLBVvAKCEidnPmGBGKklsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZopeaUrqJERSmnJI8OxjfHFQ6 xCjAwajEw7vgQUuIEGtiWXFl7iFGSQ4mJVFedY62ECG+pPyUyozE4oz4otKc1OJDjBIczEoi vMt3toYI8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8F4BGSpYlJqe WpGWmVOCkGbi4AQZzgM03JATqIa3uCAxtzgzHSJ/ilFRSpxXFyQhAJLIKM2D64WlkVeM4kCv CPN+B1nBA0xBcN2vgAYzAQ1+kQhydXFJIkJKqoFx3rm+dd12sVd2sq581cV1uem9/L/d+zen M1yr5tLZtypBcPIUmzts942Ujzd8n224R/Jyv/BDt5kid368Le3acHO5lOzLv0zbrobu3nJb mL3gm+fR0F8B5c8SFv5bppBjd8Triv5UmZfHj93nnxsfbefDXprnKX235bT5xqVuVU2Xl2hP LPqwS4mlOCPRUIu5qDgRAHcoPTj+AgAA Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:29:13 -0000 On Mon, 8 Dec 2014, Konstantin Belousov wrote: > Right now, dounmount() has the following code: > if (((mp->mnt_flag & MNT_RDONLY) || > (error = VFS_SYNC(mp, MNT_WAIT)) == 0) || (flags & MNT_FORCE) != 0) > error = VFS_UNMOUNT(mp, flags); > In other words, if the filesystem is mounted rw, we try VFS_SYNC(). > If the unmount request if forced, VFS_UNMOUNT() is called unconditionally, > otherwise, VFS_UNMOUNT() is only performed when VFS_SYNC() succeeded. > > Apparently, the sync call is problematic, both for UFS and NFS. It > was demonstrated by Peter Holm that sufficient fsx load prevents sync > from finishing for unbounded amount of time. The ffs_unmount() makes > neccessary measures to stop writers and to sync filesystem to the stable > state before destroying the mount structures, so removal of VFS_SYNC() > above fixed the test. > > More, NFS client just ignores the VFS_SYNC() call for forced unmount, > to work around the hung nfs requests. > > Andrey Gapon assured me that ZFS handles unmount correctly and does > not need help in the form of sync before unmount. The only major > writeable filesystem which apparently did not correctly synced on > unmount is msdosfs. > > Note that relying on VFS_SYNC() before VFS_UNMOUNT() to flush all caches > to permanent storage is racy, since VFS does not (and cannot) stop > other threads from writing to fs meantime. UFS and TMPFS suspend > filesystem in VFS_UNMOUNT(), handling the race in VFS_UNMOUNT(). > > I propose to only call VFS_SYNC() before VFS_UNMOUNT() for non-forced > unmount. As I explained, the call for forced case is mostly pointless. > For non-forced unmount, this is needed for KBI compatibility for NFS > (not important), and to increase the chances of unmount succeedeing > (again not important). I still prefer to keep the call around for > non-forced case for some time. It looks like VFS_SYNC is a no-op for net/openafs, so we should not be affected by this change. -Ben