Date: Sat, 25 Oct 2014 18:17:05 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Julian Elischer <julian@freebsd.org> Cc: "freebsd-fs@FreeBSD.org" <fs@freebsd.org> Subject: Re: change in VFS layer API? Message-ID: <1831388944.7492104.1414275425108.JavaMail.root@uoguelph.ca> In-Reply-To: <544BB194.3010705@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >> <julian@freebsd.org> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1831388944.7492104.1414275425108.JavaMail.root>