Date: Mon, 15 Nov 1999 18:12:09 -0500 (EST) From: Erez Zadok <ezk@cs.columbia.edu> To: Eivind Eklund <eivind@FreeBSD.ORG> Cc: fs@FreeBSD.ORG Subject: Re: namei() and freeing componentnames Message-ID: <199911152312.SAA21891@shekel.mcl.cs.columbia.edu> In-Reply-To: Your message of "Fri, 12 Nov 1999 00:03:59 %2B0100." <19991112000359.A256@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19991112000359.A256@bitbox.follo.net>, Eivind Eklund writes: [...] > 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. Will VOP_RELEASEND be able to call a filesystem-specific routine? I think it should be flexible enough. I can imagine that the VFS will call a (stackable) filesystem's vop_releasend(), and that stackable f/s can call a number of those on the lower level filesystem(s) it stacked on (there could be more than one, namely fan-out f/s). [...] > 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. [...] > Eivind. WRT performance, I suggest that if possible, we #ifdef all of the stacking code and fixes that have a non-insignificant performance impact. Sure, performance is important, but not at the cost of functionality (IMHO). Not all users would need stacking, so they can choose not to turn on the relevant kernel #define and thus get maximum performance. Those who do want any stacking will have to pay a certain performance overhead. Of course, there's also an argument against too much #ifdef'ed code, b/c it makes maintenance more difficult. I think we should realize that there would be no way to fix the VFS w/o impacting performance. Rather than implement temporary fixes that avoid "hurting" performance, we can (1) conditionalize that code, (2) get it working *correctly* first, then (3) optimize it as needed, and (4) finally, turn it on by default, possibly removing the non-stacking code. Erez. 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?199911152312.SAA21891>