Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jan 1999 21:55:45 -0500 (EST)
From:      "John S. Dyson" <dyson@iquest.net>
To:        tlambert@primenet.com (Terry Lambert)
Cc:        dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG
Subject:   Re: questions/problems with vm_fault() in Stable
Message-ID:  <199901060255.VAA02192@y.dyson.net>
In-Reply-To: <199901060044.RAA22046@usr05.primenet.com> from Terry Lambert at "Jan 6, 99 00:44:48 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said:
> > :I don't really buy this for the general case, which I believe is
> > :still stacking layers that don't access local media.
> > :
> > :For local media FS's, things which actially do I/O through a page
> > :fault, this is probably correct.
> > 
> >     Ouch.. no, get away from the 'local media' concept - it's a big time
> >     bust.  If you make the distinction between hard media and soft media
> >     (or local media verses remote media), all you do is screw up the layering 
> >     model.  Even now, traditional hard-media-backed VFS layers such as UFS 
> >     can be stacked on top of soft media layers such as MFS, which in turn 
> >     is stacked on top of SWAP (which may be a hard or soft media layer 
> >     itself).  If you throw NFS into the fray it gets worse.  It just doesn't
> >     work.  Also, these sorts of schemes require both interacting VFS layers
> >     to have knowledge about each other that goes far beyond what two 
> >     layers ought to know about each other.
> 
> The distinction I'm trying to make is between VFS layers that are VFS
> consumers and providers, and VFS layers that that are VFS providers,
> but VM system consumers.  VM system consumers are "local media" FS's.
>
The VM system is a provider :-).  The VFS provides only the file naming
abstraction.

> 
> The problem is in ensuring object coherency.  Here we have this
> enormous investment in a unified VM and buffer cache, which is mostly
> just a way for us to avoid the coherency complications that having
> seperate VM and buffer cache cause, and we're talking about doing
> something that will reintroduce the complications.
> 
Please look at the ideas again -- using the VM mechanisms for layering
eliminate the IMPOSSIBILITY for a VFS layering scheme (as it currently
is in any fashion) to provide coherence.  A bidirectional object oriented
scheme can easily provide coherence.  Tell me, what protocol exists
(or can exist) in the current VFS framework to provide coherence for
mmap, or file I/O with different layers?  Answer: none.  Thinking of
things as files begs the fact that files are all a specific instance
of a memory object, let's forget about "files" and local filesystems.
(I guess that it is possible for a VFS to provide coherence, at the
expense of continual "sync" operations -- that is just wrong.)

Think in terms of "stuff" or "objects."  The only way that coherence
can work in the current framework is in the non-layered and/or local
case.  If you get much beyond the typical filesystem structure, then
problems start arising, and hacks tend to be the expedient solution.
Rather than fight an existing structure, it seems that the correct
thing is to rethink the structure that can architecturally provide
the features needed and desired -- without hackery and special rules.

>
> Maybe I'm coming in in the middle of a long private discussion (it
> feels like it, and Julian has hinted that I am), but I think that
> its necessary to fix some of the things we all know are broken
> before we try to get tricky... my 2 cents.
> 
The problem with the VFS is that it doesn't appear to be possible to
fully fix it given the goal of coherent layering.  There is no sane way
that a lower layer invalidation can properly propagate upwards to
other consumers without treating the data (or objects) with a proper
invalidation protocol.

Any of the problems with the existing VFS/VM scheme have been with the
intricacies of dealing with VFS special cases, and dealing with the
I/O abstraction of buffers as a cache.  Forget "files" and think
"blobs of memory."  Once the notion of file is forgotten, then shadowing,
invalidation and aliasing of memory become very obvious...

I wouldn't really care if the new scheme would be called "VFS", but forget
vnodes and bp's...  They are unnecessary and undesirable abstractions except
at the lowest layers (the leaf filesystems that have those legacy concepts.)

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901060255.VAA02192>