Date: Fri, 2 Mar 2012 14:29:21 +0100 From: Peter Holm <peter@holm.cc> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r226967 - head/sys/ufs/ufs Message-ID: <20120302132921.GA40934@x2.osted.lan> In-Reply-To: <201203011647.41313.jhb@freebsd.org> References: <201110311501.p9VF1lrf020688@svn.freebsd.org> <201203011647.41313.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <citrin citrin ru> > > 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. I've been running the same test with your patch and not observed this problem. This on UFS2 with SU enabled. Regards, - Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120302132921.GA40934>