Date: Mon, 9 Mar 1998 04:59:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803090459.VAA29017@usr09.primenet.com> In-Reply-To: <199803090356.UAA14668@mt.sri.com> from "Nate Williams" at Mar 8, 98 08:56:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Can't you diff "all FS's" and "all non-stackable FS's"?
>
> What's the difference? Aren't all FS's stackable?
No. I addressed this later in the posting to which you are replying.
> > > If you want all the FS's to *require* the code, then write code for all
> > > of the existing FS in FreeBSD.
> >
> > I want them to *eventually* require the code. This is very different
> > from your characterization of my statements.
>
> Right now they *require* the code. If they don't have it, they whine
> and sometimes misbehave.
See the patch in the posting that you initially responded to. I can
send it to you directly, by itself, if you want. I have sent it to
Mike Smith, but he might be getting gun-shy about now. I wouldn't
blame him.
> > All FS's do *NOT* have to implement every VOP. All FS's do not even have
> > to implement VOP_{GET|PUT}PAGES, if they don't want to.
>
> If they don't have to, then why do they whine if they don't have it?
Because you have not applied the patch?
The reason they whine is because you won't be able to stack an FS on
top of them that required page management services. For example, a
quotafs, which must access a hidden file in the FS it is mounted over.
> So what's the point in the warning then?
See above.
[ ... ]
> > And the only "punishment" is a perfectly valid warning. Maybe it should
> > be changed to say "..stale FS code: you will not be able to stack FS's
> > on this FS!".
>
> It's violates POLA. A normal user of FreeBSD doesn't have any stacking
> FS, and he's seeing irrelevant/whiney messages that imply something bad
> about his system, when in fact there are no problems with his system.
> (There are potential problems, but if he's writing stackable FS's, then
> he should be smart enough to figure this out, shouldn't he?)
What if he's downloading binary modules and installing them, expecting
them to "just work"?
This is not an FS devloper issue.
How can I tell from above an FS whether or not the FS below me is a
stackable FS, or not? If it is, I can look for the VOP's; if it isn't,
how can I know if needed services are provided or not?
The short answer is that I need a "kernel mount flag" to tell me,
but that's not a complete answer. I also have to fill in VOPs
in my vector from the FS's below me, and propagate them up, the
more I mount. That still isn't a whole answer, but it's maybe 80%
of the way there, and a useful starting point.
I'm willing to bow to pressure to get some silence. I've discussed
this with Mike Smith, and the console warnings should be going away.
They're not useful unless you are stacking FS's, and I haven't
provided stacking FS's (yet; I depend on things like veto interfaces
and nameifree), so they should be hidden by an #ifdef.
> > > That's a total non-sequiter. LFS and NFS have brokeness way beyond the
> > > VOP_GETPAGES stuff. Getting them working require that as well as much
> > > other stuff. The reason they don't work is that their bits have rotted
> > > due to inattention.
> >
> > Software. Does. Not. Mutate.
>
> Bits. Rot. Due. To. Changes. Around. Them.
Annie. Get. Your. Noodle.
Incomplete changes around them should be backed out if they are not
addressed in a timely fashion (the standard to which I am being held,
and to which I agree, I *should* be held).
Part of this came from having nothing after the USL cease-and-desist,
and having to get *anything* that would work, and damn the torpedoes,
and I respect that part of it.
> They were broken when we got them. Their brokeness continued and was at
> times made worse due to changes made around them. If they had been used
> by someone, then they would have been maintained.
You *may* be able to make this argument about LFS, if you are arguing
with someone who doesn't understand Margo's papers, or the degree to
which the code *was* complete *and* functional. Lack of a full-featured
"cleaner" is not broken, in my opinion, it's just active research
that has yet to be completed. With the Soft Updates not exporting
a "dependency resolver registration interface" (there are reasons for
this; I've discussed them with Kirk, and neither one of us has been
able to convinve the other), an LFS is about the only way you could
build a stacking layer that implemented a VOP_TRANSACT. I would
*really* like to play with a VOP_TRANSACT. ;-).
You *can't* make that claim about Rick Macklem's NFS code. The original
breakage there was the addition of cookies to VOP_READDIR instead of some
other implementation. The code *was* functional, as provided. It looks
as if it's about to be again, thank god^H^H^HJohn Dyson.
[ ... why not all FS's are "stackable" ... ]
> Thank you.
It was nothing. I cribbed it from Heidemann. He's got broad
shoulders. 8-).
> ps. Even though I am often-times the devil's advocate here, I do
> appreciate you taking the time to answer my questions. I'm attempting
> to learn wherever I can, and since FS-101 died I'm learning wherever I
> can. :)
I understand. The still-birth of the FS-101 was a result of
impatience on my part. In a lot of cases, I simply don't have
the context in common that I would need to boil things down. That's
why I'm always referencing papers. I've taught some University
classes, but I'm willing to admit that I wouldn't be good at
starting from ground zero and building a reasonable justification.
I tend to point at papers that I think would do a much better job
of it than the hash I would make of things. 8-).
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?199803090459.VAA29017>