From owner-freebsd-fs@FreeBSD.ORG Sat Oct 25 14:20:15 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 D2119B24; Sat, 25 Oct 2014 14:20:15 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD2A2C32; Sat, 25 Oct 2014 14:20:15 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-234-114.lns20.per1.internode.on.net [121.45.234.114]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9PEKAG8079602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 25 Oct 2014 07:20:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <544BB194.3010705@freebsd.org> Date: Sat, 25 Oct 2014 22:20:04 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "K. Macy" Subject: Re: change in VFS layer API? References: <544A823A.1080304@freebsd.org> <544B0F24.4060500@freebsd.org> In-Reply-To: <544B0F24.4060500@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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 14:20:16 -0000 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? >> 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" > >