From owner-freebsd-fs@FreeBSD.ORG Sat Oct 25 22:17:06 2014 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C41FEC3B; Sat, 25 Oct 2014 22:17:06 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 67995124; Sat, 25 Oct 2014 22:17:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAHUgTFSDaFve/2dsb2JhbABcg2JYBIMCykYKhnlUAoEbAX2EAwEBBAEBASArIAsbGAICDRkCKQEJJgYIBwQBHASIIA2zc5Q1AQEBAQEBBAEBAQEBAQEbgSyPCwEBGzQHgneBVAWWT4QOhHGUQYQUIS8HgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,788,1406606400"; d="scan'208";a="162255228" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Oct 2014 18:17:05 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1BCA3B3F4B; Sat, 25 Oct 2014 18:17:05 -0400 (EDT) Date: Sat, 25 Oct 2014 18:17:05 -0400 (EDT) From: Rick Macklem To: Julian Elischer Message-ID: <1831388944.7492104.1414275425108.JavaMail.root@uoguelph.ca> In-Reply-To: <544BB194.3010705@freebsd.org> Subject: Re: change in VFS layer API? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: "freebsd-fs@FreeBSD.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 22:17:07 -0000 Julian Elischer wrote: > On 10/25/14, 10:47 AM, Julian Elischer wrote: > > On 10/25/14, 1:18 AM, K. Macy wrote: > >> On Fri, Oct 24, 2014 at 9:45 AM, Julian Elischer > >> wrote: > >>> Can anyone point me at a VFS API contract change that occurred > >>> over the last > >>> 5 years where a filesystem written to teh old contract would end > >>> up with > >>> extra references to all its vnodes/objects? Specifically a > >>> proprietary > >>> filesystem that ran on 8.0 now can be compiled but ends up with > >>> extra > >>> references on its vnodes and can not free them. > >>> > >> I think the contract for some functions has become unclear. I've > >> found > >> that the opensolaris' compatibility layer traverse' vput of the > >> initial vnode passed in triggers negative reference count panics. > >> It > >> is clear that some callers of lookup expect the reference to be > >> maintained on error so the unconditional vput was (well is - this > >> patch isn't in base) wrong, but in the case of success it isn't > >> clear. > >> Doing the vput on success will still eventually (as in a few > >> seconds > >> of this torture test script) cause a negative reference count > >> panic. I > >> think there needs to be an audit of VFS function contract > >> compliance. > >> Preferably by someone who knows what they are. I can only infer > >> from > >> cumulative context. > > > > I have evidence that the API has actually changed somehow. > > > > The old API would have extra calls to remove references to nodes. > > We don't seem to be seeing those extra calls any more. > > I'll have more info later. > My colleague who works on the filesystem in question suspects > a change in the interplay between _inactive and _reclaim of a > znode/vnode, > resulting in extra references on the nodes. > > Doesn't ring any bells with anyone? > Well, neither X_inactive() nor X_reclaim() are called until the ref count goes to 0. One quirk is that X_inactive() isn't guaranteed to be called, so anything you do in X_inactive() needs to be tested for and done again in X_reclaim(). (I have no idea if this explains why you have non-zero ref counted vnodes hanging about.) rick > > >> Thanks. > >> > >> -K > >> > >> > > > > _______________________________________________ > > 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" > > > > > > _______________________________________________ > 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" >