Date: Sun, 8 Mar 1998 20:00:47 -0700 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@mt.sri.com (Nate Williams), dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803090300.UAA13920@mt.sri.com> In-Reply-To: <199803090245.TAA15424@usr08.primenet.com> References: <199803080002.RAA05223@mt.sri.com> <199803090245.TAA15424@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Terry wants FS implementors (therefore all FS's) to explicitly write
> > code for vnode_pagers, rather than having the (potentially buggy) code
> > used by FS writers.
>
> Terry wants local media FS implementors (therefore all non-stackable
> FS's) to explicitly write code for vnode_pagers as payment for their
> direct consumption of OS-specific kernel internals.
Same thing, different way of putting it.
> > Dima wants people to not have write potentially trivial code into their
> > FS, but give them a default that will work in most cases.
>
> By use of the default vops vector, which violates the design principles
> of the stacking FS code according to both "The Design and Implementation
> of the 4.4BSD Operating System" and "Stackable Layers: An architecture
> for File System Development", both of which FreeBSD purports to pay
> lip-service to.
Screw the design when it comes to having buggy/non-working FS's. That's
one of the rules of getting your code committed. If your solution isn't
complete, then it shouldn't be committed. So, if you didn't provide
patches to *all* existing code then you should be taken out and beat
about the head and shoulders with a large noodle.
If you want all the FS's to *require* the code, then write code for all
of the existing FS in FreeBSD.
Finally, I disagree with the claim that *all* FS must implement *every*
vops operation. If so, then the 'stackable' design is broken, since in
any good design you should have the ability to use a default for common
operations.
> > Terry claims that if they rely on the trivial code, it could cause bugs.
>
> Terry claims that use of the default vops vector breaks automatic
> bypass in vfs_init.
Pray tell which existing FS break if you add the code to the default vops?
> > Dima claims that for most existing FS's, the trivial stuff is good
> > enough for their purposes, and that any FS developer that isn't writing
> > a trivial FS already is smart enough to write a non-default vnode_pager
> > implementation.
>
> Dima wants it to work the way it used to, and doesn't see any reason
> to change the existing code path in a way which is visible to Dima.
Dima (and I) are fans of POLA. Terry wants to punish people for not
doing things his way. I think reading 20 page emails is punishment
enought w/out have the FS's break (or whine alot) is overkill.
> > Terry claims that this vnode_pager stuff should go away, and it'll be
> > easier to remove it by making sure that all FS's have this code, but
> > then he loses me from that point on.
>
> Terry claims to have read the comment in /sys/vm/vnode_pager.c:
>
> /*
> * TODO:
> * Implement VOP_GETPAGES/PUTPAGES interface for filesystems. Will
> * greatly re-simplify the vnode_pager.
> */
I don't see anywhere it states that a 'default' VOP_GETPAGES can't be
added in here, vs. a VOP_GETPAGES in every [ local media ] FS.
> > Anyone silly enough to write
>
> [ local media ]
>
> > FS's should know what they're doing, and forcing them to write more
> > boilerplate code that could be done by default is simply silliness.
>
> The point is, of course, that the code *can't* be done by default, and we
> have as evidence the death of LFS and the non-function of NFS.
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.
> > If you're smart enough to write FS, you should also be smart enough to
> > figure out when the defaults won't cut it.
> >
> > This is the intent of stacking FS's as I understand. The VFS stuff is
> > intended to make FS design more OOP, so that you can pick what things
> > you need to implement, and not have to implement others, just like
> > object inheritence.
>
> For stackable FS's (which means *NOT* local media FS's) the underlying
> FS below the stack will implement the VOP_{GET|PUT}PAGES by means of
> the bypass.
So, stacking only applies to non 'local media' FS? Seems like a bad
design if it can't take care of both cases.
(BTW, can you describe succintly what a 'local media' FS is in your
terms, so that I'm not making any wrong assumptions?)
Nate
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?199803090300.UAA13920>