Date: Wed, 8 Sep 2010 02:04:33 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: freebsd-fs@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: kern/150143: [patch][tmpfs] Source directory vnode can disappear before locking it in tmpfs_rename Message-ID: <20100907230433.GA3938@tops> In-Reply-To: <201009072211.o87MB4Tg020746@chez.mckusick.com> References: <i652t2$po8$1@dough.gmane.org> <201009072211.o87MB4Tg020746@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (07/09/2010 15:11), Kirk McKusick wrote: > > To: freebsd-fs@freebsd.org > > From: Ivan Voras <ivoras@freebsd.org> > > Date: Tue, 07 Sep 2010 12:07:31 +0200 > > Subject: Re: kern/150143: [patch][tmpfs] Source directory vnode can disappear > > before locking it in tmpfs_rename > > > > On 09/06/10 09:08, linimon@FreeBSD.org wrote: > > > Synopsis: [patch][tmpfs] Source directory vnode can disappear before locking it in tmpfs_rename > > > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > > > Responsible-Changed-By: linimon > > > Responsible-Changed-When: Mon Sep 6 07:07:55 UTC 2010 > > > Responsible-Changed-Why: > > > Over to maintainer(s). > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150143 > > > > Can someone look at the patch in this PR, please? > > > > I've tested it but don't want to commit it without someone reviewing it > > (though I could commit it if the potential reviewer is busy with other > > things). > > I have not worked with tmpfs, so may not be the best person to review > this patch. But I have spent considerable time in ufs_rename, so am > familiar with the problems associated with rename. > > In reviewing your patch, it looks like a reasonable approach to the > problem. While I do not have enough context to convince myself that > it will fully fix the problem, it certainly should help rename work > better. Hello Kirk, I was working on improving namecache during this summer, and I have to admit rename with the biggest problem of all, and it still remains. There are several common approaches taken by filesystems. UFS locks all vnodes involved in rename, unlocking, trying to lock vnodes and check for races, tmpfs does something similar (although vnode locking is incorrect, I'm going to fix it a bit later). Some others (like ext2fs and msdosfs if I'm not mistaken) keep locking at minimum, it seems to work, but honestly I don't see why it can't race. ZFS is somewhat unique in this respect. It uses name locking, keeps per directory table of locked file names, i.e. names that can't change while in table. So that destination file won't be added during rename, source file can't disappear, etc. What do you think about name locking approach taken by ZFS? Are there any drawbacks you are aware of? I was thinking of trying to unify rename locking, either make UFS approach standard, i.e. lock all vnodes outside of rename or use name locking similar to ZFS. UFS way may not fit well into existing VOP API (extra vnode lookups to check for races) besides vnode locking order remains an important issue. ZFS style locks may be interesting in a way that they would allow to reduce scope of vnode locks, especially considering merging with ongoing work on rangelocks (just a guess). Thanks, Gleb. > > Kirk McKusick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100907230433.GA3938>