Date: Mon, 9 Mar 1998 02:45:58 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: dima@tejblum.dnttm.rssi.ru, tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803090245.TAA15424@usr08.primenet.com> In-Reply-To: <199803080002.RAA05223@mt.sri.com> from "Nate Williams" at Mar 7, 98 05:02:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Tell me what I'm missing, if anything?
> 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.
FFS consumes 151 kernel functions; about 120 more than it should.
> 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.
> 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.
> 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.
> 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.
*/
> 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. In addition,
we have the implied comments about VOP_GETPAGES being necessary through
its existance in various working FS implementations.
> 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.
Because of this, yoy are mixing the idea of writing a non-stackable local
media FS (it can only be stacked *on top of* because it does not properly
implement a bottom end that is identical to its top end; it's bottom
end is the kernel interfaces to subsystems like VM) and a stackable FS
(for which your second paragraph is true).
People, *PLEASE* read Heidemann's paper before making comments on FS
architecture! It is *the* architectural refrence for the BSD 4.4 stacking
vnode interface!
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?199803090245.TAA15424>