Date: Tue, 27 Jan 1998 05:41:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@FreeBSD.ORG Cc: tlambert@primenet.com, scottm@cs.ucla.edu, freebsd-current@FreeBSD.ORG Subject: Re: stable current? Message-ID: <199801270541.WAA00264@usr01.primenet.com> In-Reply-To: <199801260248.VAA00479@dyson.iquest.net> from "John S. Dyson" at Jan 25, 98 09:48:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, you are right, and the code supports it.
>
> Following up my own comments:
I'll follow up the other comments tomorrow, when I have time to grovel
the code at the same time I am typing. This will, in brief, point to
the specific issue I'm referencing inre: stacking.
> The pager code has supported whatever the filesystems do. This becomes
> more of an issue with the layered filesystems, and the major impediment
> that we have had is that the VM object could not be shared across vnodes,
> and now it can. (Theoretically, we could layer UFS onto other filesystems,
> but I am not worried about that right now.)
The existance of aliases (ie: the act of sharing the object across
vnodes) is fraught with peril. You may, in fact, have corrected this
in the most recent code; I haven't updated my experimental system
for some time.
The aliasing of objects is precisely what was causing the "nullfs is
not very null" series of changes to be a *bad* idea.
The problem here is that if an FS does not support a VOP_{GET|PUT}PAGES,
you can't tell whether it's because the FS truly does not understand it,
or if you should use the bypass. Until all physical media FS's natively
support it (I'm willing to hack on this if you are willing to commit the
code), then you can't know that a NULL descriptor value in, say, nullfs
or unionfs, means that the FS itself can't handle it, and you need to
back off to the algorithm with promiscuous knowledge of where the pages
are hung off the vnode. This algorithm assumes the top level vnode; for
any stack, this is guaranteed to be an alias. Aliases are bad because
they are hard to get right. Again, you might have gotten them right;
I don't know. Really, you want to be able to ask "does the vnode
backing this object support these interfaces?". You can't really ask
that right now.
Once you can ask that, maybe I screwed up in recommeneding the use
of VOP_{GET|PUT}PAGES; if you can ask for the backing object, you
can then run the old vnode_pager on the backing object instead of
on the top level vnode. You can also access your lock list through
the backing vnode's lock list (if the advisory locks were hung there),
so maybe this is a better approach. I don't know yet.
But aliases are a problem because of downward synchronization; even if
you've taken care of it, it's a problem becauses of unnecessary code
bloat, such as was contemplated in nullfs and unionfs.
> Sure there are some layering issues as you have suggested, but I have
> also known about them. There has been alot more wrong than even you
> have ever talked about (at least to me.)
Well, come back to town and let me buy you a pizza and talk your ear off...
;-).
I never said that I knew all of the answers; only some of the questions,
and what I thought were some (a smaller number) of the answers.
> If this was an easy thing to fix, I would have a long time ago. There
> are few, if any revelations in what you have said, but damn it, it doesn't
> hurt to work in parallel, until I hear complaints that don't solve them,
> or someone who discounts the complexity of problems.
>
> Almost none of the problems that we have had are due to the conventional
> filesystem implementations. I can write a native getpages or putpages in
> a few hours. It is the layering, and the vnode pager is pretty much not
> an issue, and hasn't been for the last 2yrs. If the vnode pager implements
> a default getpages or putpages interface, who cares? The layered filesystems
> will supply their own.
The intermediate layers will *not* necessarily supply their own. This
is the purpose of the bypass. But to do a bypass, you have to be able
to be sure that there's something at the end of the detour before you
go down the road, and find nothing but a "sever tire damage will result!"
sign. 8-).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801270541.WAA00264>