From owner-svn-src-head@FreeBSD.ORG Mon Mar 5 21:44:04 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7E8F1065670 for ; Mon, 5 Mar 2012 21:44:04 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 863088FC1A for ; Mon, 5 Mar 2012 21:44:04 +0000 (UTC) Received: (qmail 44020 invoked from network); 5 Mar 2012 21:43:57 -0000 Received: from 87.58.144.241 (HELO x2.osted.lan) (87.58.144.241) by relay02.pair.com with SMTP; 5 Mar 2012 21:43:57 -0000 X-pair-Authenticated: 87.58.144.241 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.4/8.14.4) with ESMTP id q25Lht2W041441; Mon, 5 Mar 2012 22:43:55 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.4/8.14.4/Submit) id q25Lhs9S041438; Mon, 5 Mar 2012 22:43:54 +0100 (CET) (envelope-from pho) Date: Mon, 5 Mar 2012 22:43:54 +0100 From: Peter Holm To: John Baldwin Message-ID: <20120305214354.GA41216@x2.osted.lan> References: <201203021153.06614.jhb@freebsd.org> <1978600220.298005.1330754492306.JavaMail.root@erie.cs.uoguelph.ca> <20120303163843.GA72020@x2.osted.lan> <201203051238.57501.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203051238.57501.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Rick Macklem , src-committers@freebsd.org Subject: Re: svn commit: r226967 - head/sys/ufs/ufs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:44:05 -0000 On Mon, Mar 05, 2012 at 12:38:57PM -0500, John Baldwin wrote: > On Saturday, March 03, 2012 11:38:43 am Peter Holm wrote: > > On Sat, Mar 03, 2012 at 01:01:32AM -0500, Rick Macklem wrote: > > > John Baldwin wrote: > > > > On Friday, March 02, 2012 8:29:21 am Peter Holm wrote: > > > > > On Thu, Mar 01, 2012 at 04:47:41PM -0500, John Baldwin wrote: > > > > > > On Monday, October 31, 2011 11:01:47 am Peter Holm wrote: > > > > > > > Author: pho > > > > > > > Date: Mon Oct 31 15:01:47 2011 > > > > > > > New Revision: 226967 > > > > > > > URL: http://svn.freebsd.org/changeset/base/226967 > > > > > > > > > > > > > > Log: > > > > > > > The kern_renameat() looks up the fvp using the DELETE flag, > > > > > > > which causes > > > > > > > the removal of the name cache entry for fvp. > > > > > > > > > > > > > > Reported by: Anton Yuzhaninov > > > > > > > In collaboration with: kib > > > > > > > MFC after: 1 week > > > > > > > > > > > > > > Modified: > > > > > > > head/sys/ufs/ufs/ufs_vnops.c > > > > > > > > > > > > So I ran into this at work recently, and even this fix applied I > > > > > > was still > > > > > > seeing rename()'s that were seemingly not taking effect. After > > > > > > getting some > > > > > > extra KTR traces, I figured out that the same purge needs to be > > > > > > applied to the > > > > > > destination vnode. Specifically, the issue I ran into was that was > > > > > > renaming > > > > > > 'foo' to 'bar', but lookups for 'bar' were still returning the old > > > > > > file. The > > > > > > reason was that a lookup after the namei(RENAME) of the > > > > > > destination while > > > > > > ufs_rename() had its locks dropped was readding the name cache > > > > > > entry for > > > > > > 'bar', and then a cache_lookup() of 'bar' would return the old > > > > > > vnode as long > > > > > > as that vnode was valid (e.g. if it had a link in another > > > > > > location, or other > > > > > > processes had an open file descriptor for it). I'm currently > > > > > > testing the > > > > > > patch below: > > > > > > > > > > > > > > > > I now have a scenario that fails, but not quite the same way you > > > > > describe. > > > > > > > > > > It looks like this: > > > > > > > > > > touch file1 > > > > > echo xxx > file2 > > > > > rename(file1, file2) > > > > > > > > > > A different process performs stat() on both files in a tight loop. > > > > > > > > > > Once in a while I observe that a stat() of file2, after the rename, > > > > > returns a link count of zero. Size is zero as expected, but the > > > > > inode > > > > > number of file2 is unchanged. > > > > > > > Peter, were you doing a stat() using the file name, or an fstat()? > > > (Using stat() with afile name might explain it, maybe??) > > > > > > > Yes. Switching to open()/fstat() of the "from" file in the loop, makes > > the cache problem go away. > > Using fstat avoids the changes of getting a stale name cache, so it just > avoids the race altogether. However, there is no reason I can think of why > stat() should ever give you can inconsistent view of attributes. You should > always get a consistent snapshot of attributes. > Maybe my test scenario is broken, but it sure looks like the link count is zero, after the rename. $ ./r9.sh FAIL: old and new "To" inode number is identical stat() before the rename(): fromFile.log : ino = 4, nlink = 1, size = 0 toFile.log.00065: ino = 70, nlink = 1, size = 8 stat() after the rename(): toFile.log.00065: ino = 70, nlink = 0, size = 0 $ This on r232558 with r232401 reverted. No problem on a pristine HEAD of cause. http://people.freebsd.org/~pho/r9.sh - Peter