From owner-freebsd-current Sun Mar 8 17:36:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15833 for freebsd-current-outgoing; Sun, 8 Mar 1998 17:36:32 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15828 for ; Sun, 8 Mar 1998 17:36:30 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA27378; Sun, 8 Mar 1998 18:36:30 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd027335; Sun Mar 8 18:36:22 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA12054; Sun, 8 Mar 1998 18:36:17 -0700 (MST) From: Terry Lambert Message-Id: <199803090136.SAA12054@usr08.primenet.com> Subject: Re: vnode_pager: *** WARNING *** stale FS code in system To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 9 Mar 1998 01:36:17 +0000 (GMT) Cc: nate@mt.sri.com, dima@tejblum.dnttm.rssi.ru, tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <10803.889345727@critter.freebsd.dk> from "Poul-Henning Kamp" at Mar 8, 98 09:28:47 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Tell me what I'm missing, if anything? > > You're absolutely right. Terry is obfuscating the argument because > he is trying to cover up for the fact that he didn't realize what > the default operations vectors were there for. Nice of you to chime in with an assumption about what is in my head, Poul. The reason for the default ops vectors is to implement the operations that an FS doesn't want to implement itself. You will notice that this is a violation of the stacking architecture noted in Figure 6.14 on page 234 of "The Design and Implementation of the 4.4BSD Operating System", which levels that avenue for "appeal to authority". You can achieve the same functionality ad the default vops by placing the vop_* functions in the apropriate vnodeopv_entry_desc's, or in the case where you want FS specific implementations, and the use of the functions are a temporary bandaid (as in a generic {get|put}pages), you can provide stub functions (which I did). I note that the use of the default vops breaks FS stack bypass compression at vfs_init time for a given stack instance. Rather than calling to the immediately inferior node, the highest level node in a stack's VOP vector for an uniplemented vector should be passed upwards. If an FS "doesn't want" to implement a VOP, then either the VOP should fail, or the FS should only be used in a context where it is stacked on top of another FS whic *does* implement the VOP. In fact, we see by looking at Kirk McKusick's Suft Updates implementation that a number of the "optimizations" wrought by the default vops in fact *break* existing functionality, where UFS/FFS are not considered as a monolithic object. Returning to first principles, we see that Heidemann specifically cautions against this type of "optimization": Reuse of layers is enhanced whe each layer encompasses few abstractions. If layer crossing overhead is at all significant, modular filing environments will either suffer serious performance penalties (relative to non- layered environments), or layers will be combined, making layer reuse more difficult. Go read John Heidemann's Thesis: ftp://ftp.cs.ucla.edu/pub/ficus/heidemann_thesis.ps.gz Since he invented the thing, why don't we just find out what the inventor intended instead of speculating about "what Terry does or doesn't know about his intent"? Pay attention to 1.2.1, where he makes the case for symmetric interfaces. Pay attention also to the content of chapters 2 & 3, in which he makes the case that the default should be to facilitate stacking, his comments on efficiency, opacity, and limits. Technically, local media FS's, as they are implemented in BSD, do not meet the definition of stacking layers: The key characteristic of a stackable layer is that it possess the same interface above and below. If you need clarification of any issues raised by his paper, let me know, and I can send you his email address (if you won't accept my clarifications), since I have probably asked many of the same questions since first corresponding with him on the subject of rolling the code into BSD 4.3 derived 386BSD, back in 1994. While you are at it, why don't you send Kirk McKusick some mail; don't reference anyone by name so you don't bias him one way or the other (after all, I've probably had dinner with him more recently than you). Ask him how he feels, in general, about whether or not there should be FS specific VOP_{GET|PUT|}PAGES code. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message