From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 28 17:39:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FC751065697 for ; Wed, 28 Oct 2009 17:39:58 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1650C8FC43 for ; Wed, 28 Oct 2009 17:39:57 +0000 (UTC) Received: by bwz1 with SMTP id 1so1368441bwz.13 for ; Wed, 28 Oct 2009 10:39:56 -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 :content-transfer-encoding:in-reply-to:user-agent; bh=HigF2N+gK6sPFhljpT3jrELM0uhkW/fye7QVO5iwknk=; b=Ngz8FuH42MY7lWh11CSGLQxINBner8ChSbZNh50S+NoiyjY732YT9tFjsG5qx/QpK0 nTXjWSCRNNK9bexnyPx97jxt8qUQtqPmQ+hkAgPOaTihvETtdM63DBwQZuBCA0w25OlQ i3gs25y+VwHbiMM+eRakXiPq57DtLIMLhNnzE= 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:content-transfer-encoding :in-reply-to:user-agent; b=jd3+cQlM/ff0gl2V8Zt3AyQVvxeccPvH9iskuvYyvrW5WJagCH3RJo0e/BFSulHicp wzF+kukwfCEsgk0UhQ4E3+1QVdcBvWh7i5HBAJ/O/Y19Nt74T3FmhPSuW72l+8Prddxo 412kGHvrF9N7YdizM1kThWJQ4AqQknpc57p+g= Received: by 10.204.154.155 with SMTP id o27mr1768624bkw.198.1256750183537; Wed, 28 Oct 2009 10:16:23 -0700 (PDT) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 12sm2180201fks.8.2009.10.28.10.16.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 10:16:21 -0700 (PDT) Date: Wed, 28 Oct 2009 19:15:51 +0200 From: Gleb Kurtsou To: Linda Messerschmidt Message-ID: <20091028171550.GA1909@tops> References: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> <20091028124832.GA7852@pm513-1.comsys.ntu-kpi.kiev.ua> <237c27100910280648k597e2159sf4fd663fe7b77b3b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <237c27100910280648k597e2159sf4fd663fe7b77b3b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Andrey Simonenko , freebsd-hackers@freebsd.org Subject: Re: FreeBSD 7.2 + NFS + nullfs + unlink + fstat = Stale NFS File Handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:39:58 -0000 On (28/10/2009 09:48), Linda Messerschmidt wrote: > On Wed, Oct 28, 2009 at 8:48 AM, Andrey Simonenko > wrote: > > As I understand when a file is opened in NULLFS its vnode gets new > > reference on 'count of users', but this new reference is not propagated > > to the lower vnode (vnode that is under NULLFS).  When a file is removed > > NULLFS passes this op to the lower FS (NFS in this example) and that > > FS sees that its vnode has only a single reference on 'count of users'. > > > > In case of NFS when there is a request to remove a vnode it checks that > > value of 'count of users' for this vnode.  If this count is equal to 1, > > then NFS client code does 'RPC remove'.  If this count is greater than 1 > > (for example when a file is opened), then NFS client code renames pathname > > to .nfs-file, but does not send 'RPC remove' to the NFS server. > > That sounds like a pretty reasonable explanation of what's going on. > > Unfortunately it does sound like this would be tough to fix. Since > NFS deletes are a special case, short of making an NFS-aware nullfs, > which seems silly, it sounds like the "solution" would be rewriting > nullfs to propagate the reference count. I don't know enough about > nullfs to know exactly how hard that would be, but I'm guessing it's > not the work of a lazy afternoon. :-) I think that's not about nullfs. Nullfs behaves correctly. It grabs reference for a vnode and even tries too release it as soon as possible. NFS logic is wrong here, imho. vrefcnt(vp) == 1 supposed to mean that vnode is going to be reclaimed on next reference release and nothing more. And it doesn't mean that reference is going to be released any time soon. Although network filesystems in the tree abuse it the same way NFS does. Probably what NFS tries to do is to check if file descriptor is opened for a vnode. This assumption holds only for a single code path out of many: syscall by user. But there is plenty of code invoking vnode operations without even allocating file descriptor. Propagating per file descriptor reference counting into filesystem itself is a layer violation and should be avoided in my opinion. There should be a way to fix NFS by replacing vrefcnt check. > >>       if (!fd) { > >           ^^^^^ should be (fd < 0) > > Oops, you are right! > > Thanks very much! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"