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 Message-ID: <Pine.BSF.4.10.9911111509340.17330-100000@current1.whistle.com> In-Reply-To: <19991112000359.A256@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911111509340.17330-100000>