Date: Mon, 2 Mar 1998 01:10:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Cc: tlambert@primenet.com, FreeBSD-current@FreeBSD.ORG Subject: Re: VM: Process hangs sleeping on vmpfw Message-ID: <199803020110.SAA07018@usr04.primenet.com> In-Reply-To: <199803020018.DAA01416@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Mar 2, 98 03:18:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I don't see why default ops doesn't solve stacking problems.
> >
> > Because they provide a default operation for every FS, even FS's
> > you want to use the bypass instead.
>
> Stacking layers supposed to use generic bypass routine, like this:
> { &vop_default_desc, (vop_t *) null_bypass },
> This is the whole point of stacking layers --- they can bypass any
> operation that they don't need to handle specifically.
>
> If you disagree with the above statement, you can anyway put
> vop_stdgetpages and vop_stdputpages to each local media filesystem's
> vnops table, instead of cut&paste the trivial implementation (I repeat
> it 3rd time, since I didn't seen an answer to it).
That's exactly what the generic code is.
The decomplication is supposed to occur when we implement FS specific
getpages/putpages, instead of using the generic version (exactly the
same as your defaultops version, except for the a_offset stuff, which
is ignored by the previous and current implementations).
The point in doing it the way it's currently being done is that the
FS's can be handled on a case-by-case basis. There's no clear line
of demarcation in the defaultops implementsion: when do you get rid
of the defaultops implementation? How do you tell it is no longer
referenced?
> Also, stacking layers will not use the default anyway, if they are
> going to work. So I wouldn't count them as vote against getpages/putpages
> in the default ops table. If they cannot use a generic bypass, no
> one warning will save them from lot of troubles.
No. But the warning *will* tell *me* to write code. If someone has
a problem, it's more likely that I will get information given the
warning than I will without it. Without it, people will need to
understand the FS stacking code. This is unlikely, even if I (and you)
do understand what's going on here.
> > Ideally, there will be *no* default ops. This was the point of
> > John's comments about simplification in the vnode_pager code.
>
> The comment is there for years.... I will wait until it actually
> happens.
The problem is "how can I incrementally get there from here?". The
problem is how to present it as evolution when in fact, it is revolution.
This is equivalent to the "show your work" requirement in calculus tests;
you may be able to intuitively arrive at the right answer, but unless you
explain your intuition (mathematicians are hard-asses), you can't use
it as an answer.
> > > > You should also follow the NFS case in vnode_pager_generic_getpages
> > > > and look at all the other vp->v_mount references. Look what the
> > > > change means to VOP_BMAP, specifically with regard to the assumptions
> > > > comment in vnode_pager_generic_getpages and vnode_pager_input_smlfs's
> > > > being called -- with the same assumptions but without the test. It's
> > > > pretty obvious that the VOP_BMAP return test is equal to the NFS
> > > > test. This code is at the heart of a lot of problems, and I'd like
>
> Obvious, but doesn't true. NFS implement VOP_BMAP 8-).
Yes, it does. That's the source of the problem here. As John said,
and I've insisted for some time, the problem is in the aliases.
I will compromise by providing patches for the affected FS's, on the theory
that "anything that works is better than anything that doesn't"...
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?199803020110.SAA07018>