From owner-freebsd-hackers Wed Jan 6 14:59:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18444 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 14:59:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18438 for ; Wed, 6 Jan 1999 14:59:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA25909; Wed, 6 Jan 1999 14:59:19 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Jan 1999 14:59:19 -0800 (PST) From: Matthew Dillon Message-Id: <199901062259.OAA25909@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : system calls NFS server VFS : ------------ ---------- --- : VFS VFS VFS : :In the provider case, where the VFS consumer is, you have three :cases as well: : : VFS VFS VFS : --- ---------- --- : VM NFS client VFS : :Again, in the -current code, only the first one works correctly in I think you have to get away from thinking about 'consumers' and 'providers'. It is precisely this sort of thinking that screwed up the existing VFS design. The best way to abstract a VFS layer is consider that each VFS layer has a 'frontside' and 'backside'. The VFS layer should make no assumptions whatsoever as to who attaches to it on the frontside, and who it is attached to on the backside. If you really want, you could consider a 'consumer' to be the VFS layer's backside and a 'provider' to be the SAME VFS layer's frontside. So a VFS layer's backside 'consumer' is linked to another VFS layer's frontside 'provider'. And so forth. But don't try to 'type' a VFS layer -- it doesn't work. It was precisely that sort of thinking that required something like the MFS filesystem, which blurs distinctions, to be a major hack in existing kernels. The only way to do cache coherency through a multi-layered VFS design is to extend the vm_object model. You *cannot* require that a VM system use VOP_GETPAGES or VOP_PUTPAGES whenever it wants to verify the validity of a page it already has in the cache. If a page is sitting in the cache accessible to someone, that someone should be able to use the page immediately. This is why a two-way cache coherency protocol is so necessary, so things that effect coherency can be propogated back up through the layers rather then through hacks. Requiring the GET/PUTPAGES interface to be used in a cache case destroys the efficiency of the cache and, also, makes it virtually impossible to implement async I/O. The VFS layer, as it stands, cannot do async I/O - the struct buf mechanisms 'sorta' does it, but it isn't really async due to the huge number of places where the system can block even before it returns a bp. An extended vm_object and cache coherency model would, for example, allow something like MFS, VN, or VINUM to be implemented almost trivially and definitely more efficiently, even unto having filesystems relocate underlying storage on the fly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message