From owner-freebsd-current Sun Jan 25 18:48:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22290 for current-outgoing; Sun, 25 Jan 1998 18:48:38 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22282; Sun, 25 Jan 1998 18:48:31 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id VAA00479; Sun, 25 Jan 1998 21:48:29 -0500 (EST) (envelope-from toor) Message-Id: <199801260248.VAA00479@dyson.iquest.net> Subject: Re: stable current? In-Reply-To: <199801260225.VAA00373@dyson.iquest.net> from "John S. Dyson" at "Jan 25, 98 09:25:26 pm" To: dyson@FreeBSD.ORG Date: Sun, 25 Jan 1998 21:48:29 -0500 (EST) Cc: tlambert@primenet.com, dyson@FreeBSD.ORG, scottm@cs.ucla.edu, freebsd-current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk John S. Dyson said: > > Well, you are right, and the code supports it. > Following up my own comments: 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.) 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.) 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. Figure this: I fixed our object reference problem in about 3-4wks. PHK has fixed the vnode caching/reference problem over at least several weeks (I don't know how long.) I can fix the entire FS layering problem in two weeks full time. I can add getpages/putpages to UFS in an hour (we already have a valid getpages/putpages for UFS anyway :-)). Tell me where most of the work is? The time to implement a getpages and putpages is childs-play. The layering structure itself has been in place for two years. Again, read-my-lips, we already have the getpages/putpages abstraction. For example, vnode_pager uses VOP_WRITE for UFS filesystem putpages. (That is totally valid, if not slightly more inefficient than it might be.) vnode_pager uses ufs_getpages which uses spec_getpages for UFS filesystem getpages. (That is also totally valid, and is an example of a full implementation of the abstraction.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.