Date: Mon, 9 Mar 1998 01:36:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: nate@mt.sri.com, dima@tejblum.dnttm.rssi.ru, tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803090136.SAA12054@usr08.primenet.com> In-Reply-To: <10803.889345727@critter.freebsd.dk> from "Poul-Henning Kamp" at Mar 8, 98 09:28:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803090136.SAA12054>