From owner-freebsd-fs@FreeBSD.ORG Wed Aug 23 04:40:55 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7ACB16A4DD for ; Wed, 23 Aug 2006 04:40:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E4C43D45 for ; Wed, 23 Aug 2006 04:40:54 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k7N4ej2v018159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 07:40:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k7N4eksB094117; Wed, 23 Aug 2006 07:40:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k7N4ehE4094116; Wed, 23 Aug 2006 07:40:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2006 07:40:43 +0300 From: Kostik Belousov To: Tor Egge Message-ID: <20060823044043.GA64800@deviant.kiev.zoral.com.ua> References: <20060821.132151.41668008.Tor.Egge@cvsup.no.freebsd.org> <20060822175540.V58720@delplex.bde.org> <20060822130743.GL56637@deviant.kiev.zoral.com.ua> <20060822.214638.74697110.Tor.Egge@cvsup.no.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20060822.214638.74697110.Tor.Egge@cvsup.no.freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Deadlock between nfsd and snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 04:40:56 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 22, 2006 at 09:46:38PM +0000, Tor Egge wrote: > > 2. All places that currently set IN_ACCESS, instead would increment > > i_accessed using the atomic ops. ufs_itimes shall update i_access > > under some mutex if i_accessed is greater than zero. > > Protecting the existing i_flag and the timestamps with the vnode > interlock when the current thread only has a shared vnode lock should > be sufficient to protect against the races, removing the need for #3, > #4 and #4 below. > > What's left is avoiding setting IN_MODIFIED when it's unsafe, to > protect against the deadlock. So, I will do the following: 1. Protect both setting and reading inode times and i_flag with vnode interlock. This shall be done through all the sys/ufs/*/* code. 2. Modify ufs_itimes: > If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe to > set IN_MODIFIED since the file system might be suspended or in the > process of being suspended with the vnode sync loop in ffs_sync() > having iterated past the vnode. In other words, if IN_CHANGE or IN_UPDATE are already set, I can safely convert IN_ACCESS into IN_MOD. Otherwise, I shall implemented the algorithm below. Suspending/suspended checks need to take MNT_ILOCK. > > If the file system is suspended then IN_MODIFIED cannot be set. If > IN_MODIFIED, IN_CHANGE or IN_UPDATE is set and the file system is > suspended then something is wrong. > > If the file system is in the process of being suspended then > IN_MODIFIED can be set at the cost of triggering a restart of the > vnode sync loop in ffs_sync(). If either IN_MODIFIED, IN_CHANGE or > IN_UPDATE is already set then the vnode sync loop has not reached the > vnode, and a restart isn't needed. > > When ufs_itimes() cannot set IN_MODIFIED then it has to either risk > losing the access time update or use some mechanism to defer it (e.g. > set IN_LAZYMOD or a new flag and let process_deferred_inactive() set > IN_MODIFIED after the file system has been resumed). > BTW, shall the test for MNT_RDONLY in the ufs_itimes moved earlier ? 3. Add the process_deferred_lazymod procedure, called from ffs_snapshot before proc_deferred_inactive, that shall convert IN_LAZYMOD | IN_ACCESS into IN_MODIFIED. To be safe, the proc_def_lazymod needs vn_start_write braces. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE69xLC3+MBN1Mb4gRAqsrAKCEh5Tb/vYlSAXLGErJJP6AeE6H0ACcCN/O gDmX+uH3k1p+6QZWJcOY+nk= =hPmb -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--