From owner-freebsd-fs  Thu Nov 11 15:10:28 1999
Delivered-To: freebsd-fs@freebsd.org
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id D9B0E14F66; Thu, 11 Nov 1999 15:10:25 -0800 (PST)
	(envelope-from julian@whistle.com)
Received: from current1.whiste.com (current1.whistle.com [207.76.205.22])
	by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA96628;
	Thu, 11 Nov 1999 15:10:24 -0800 (PST)
Date: Thu, 11 Nov 1999 15:10:23 -0800 (PST)
From: Julian Elischer <julian@whistle.com>
To: Eivind Eklund <eivind@FreeBSD.ORG>
Cc: fs@FreeBSD.ORG, terry@lambert.org
Subject: Re: namei() and freeing componentnames
In-Reply-To: <19991112000359.A256@bitbox.follo.net>
Message-ID: <Pine.BSF.4.10.9911111509340.17330-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

didn't terry have some patches for this?


On Fri, 12 Nov 1999, Eivind Eklund wrote:

> I would like to make this reflexive - "symmetrical" allocation and
> free, like it presently is supposed to be with SAVESTART (but isn't -
> there are approximately one billion bugs in the code).
> 
> I suspect that for some filesystems (though none of the present ones),
> it might be necessary to do more than a
> zfree(namei_zone,cnp->cn_pnbuf) in order to free up all the relevant
> data.  In order to support this, we'd have to introduce a new VOP -
> tentatively called VOP_RELEASEND().  Unfortunately, this comes with a
> performance penalty.
> 
> As we presently do not need this capability, I am thinking of
> "faking" VOP_RELEASEND() - make it into a macro similar to this:
> #define VOP_RELEASEND(vp, cnp) do {			\
> 	(void)(vp);   /* Do side effects of (vp) */	\
> 	zfree(namei_zone, (cnp)->cn_pnbuf;		\
> } while (0)
> 
> This is somewhat vile, but has the advantage of keeping the code ready
> for the real VOP_RELEASEND(), and not loosing performance until we
> actually get some benefit out of it.
> 
> Do the rest of you consider it too vile to do, or is it an OK
> tradeoff?  (Personally, I consider it an OK tradeoff.)
> 
> It also allows an evil hack:
> The NFS code is rather incestuous with the VFS system, in order to
> minimize the amount of cached data during NFS requests.  One side of
> this is that it seems to throw away the vnode we'd like to use for
> VOP_RELEASEND() - before it wants to throw away the componentname.
> With the macro, NFS could use VOP_RELEASEND(NULL, <stuff>); for the
> time being, crashing in a very obvious way when we find we need to
> introduce the actual VOP.  This avoids re-structuring the NFS code
> until we actually get benefits from VOP_RELEASEND.
> 
> Is it too evil?  I'm of two minds - I don't like messing more than
> necessary with the NFS code (and isn't sure I could do the messing
> without performance impact), but I'm not exactly ecstatic about the
> hack, either.
> 
> I've got first pass patches for the above (not tested, not compiled,
> not done the three different forms of review for errors I'm planning
> to do).
> 
> Eivind.
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message