From owner-freebsd-fs@FreeBSD.ORG Tue Sep 7 23:22:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C4410656DC; Tue, 7 Sep 2010 23:22:21 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F380C8FC13; Tue, 7 Sep 2010 23:22:19 +0000 (UTC) Received: by eyx24 with SMTP id 24so3055053eyx.13 for ; Tue, 07 Sep 2010 16:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=e1qz+V83viNnLpUfUwzy1calGQQmlbWcnEdJ3GwaYuM=; b=s9nOlgBv6/qPD3N5CHvbFOLmxEcq65r0P5bO2Ep2mhh4ObqRjKarZZ5XE/fz1xKhf6 43Nqn7Yc+qp033+TwvVRYtVWUHO8Zj1GnkVEDP2uJslQWZUKT5/MwXEGr7lz+rQS3wop rGEPArDpwh+SSYTDWJTeMSZLshCYQM8xFcoM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=bgEVEEn8gggTOujMhLPtfGt3k3YckwFzBmjitXYX2xYXqxff5w69JpkKgpS2cbvuyY /uNkjoLgdwNKZmrnAAGDV5BpUje2WkF7gvSRyZRLoM1OhB9Y7d6zVVKfAvVWpj0+c80w +0mdzHhSYTg2aJgHDk3MRWnllvh9rPKwCn/x4= Received: by 10.213.101.10 with SMTP id a10mr11229ebo.85.1283900679619; Tue, 07 Sep 2010 16:04:39 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id u9sm10768183eeh.17.2010.09.07.16.04.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 16:04:38 -0700 (PDT) Date: Wed, 8 Sep 2010 02:04:33 +0300 From: Gleb Kurtsou To: Kirk McKusick Message-ID: <20100907230433.GA3938@tops> References: <201009072211.o87MB4Tg020746@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201009072211.o87MB4Tg020746@chez.mckusick.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: kern/150143: [patch][tmpfs] Source directory vnode can disappear before locking it in tmpfs_rename 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: Tue, 07 Sep 2010 23:22:21 -0000 On (07/09/2010 15:11), Kirk McKusick wrote: > > To: freebsd-fs@freebsd.org > > From: Ivan Voras > > 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"