From owner-freebsd-fs Thu Nov 11 15: 4:20 1999 Delivered-To: freebsd-fs@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 312C114E4A for ; Thu, 11 Nov 1999 15:04:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA02575 for ; Fri, 12 Nov 1999 00:04:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA14093 for fs@FreeBSD.org; Fri, 12 Nov 1999 00:04:14 +0100 (MET) Date: Fri, 12 Nov 1999 00:03:59 +0100 From: Eivind Eklund To: fs@FreeBSD.org Subject: namei() and freeing componentnames Message-ID: <19991112000359.A256@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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, ); 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