Date: Tue, 5 Jan 1999 14:36:28 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: tlambert@primenet.com (Terry Lambert), dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901052236.OAA97860@apollo.backplane.com>
next 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.
:>
:Actually, the VM approach works really well for non-local filesystems
:also. How do you pass a bp or vp around across systems??? Hmmm???
:The VM object abstraction simply names data, and has validity info
:that can be passed from layer to layer. The VFS abstraction is
:messed up with the concept of "vnode" and "bp", etc. Those don't
:mean ANYTHING across machines.
:..
It's kinda unfair to bring Terry & freebsd-hackers in without
some context - what Johh is saying is coming out of a much
longer discussion that has been occuring in private email
amoungst three or four of us in regards to VM/VFS system
cleanups.
What it comes down to is how to find the right abstraction to
do the job without blowing efficiency out of the water. John
has come to the conclusion (which I have also now come to, and
I think a number of others too but are still worried about making
such major changes to the VFS APIs and disrupting certain ongoing
projects... it hasn't been put forth on -hackers or -current
mainly to avoid starting a flame war) ... we've come to the
conclusion that VFS is badly flawed and basically needs to be
replaced.
In talking about the basic I/O mechanisms to replace it with,
John (and now I) have come to the conclusion that the best
mechanism is to extend the vm_object_t object model into the
VFS system. The VM object module is *already* heavily hacked
into the VFS/BIO model to handle deficiencies in VFS/BIO.
Extending the VM object model and getting rid of the VFS/BIO
model actually isn't as bad as it sounds and would clean up
a lot of junk.
Before this came up outside our little group we were getting
into a discussion as to how to appropriately extend the VM
object model to cover VFS operations and maintain cache
coherency (something the current VFS system doesn't do at all
without a whole lot of hacking) without screwing up efficiency.
This is where John's bi-directional IPC comments come into
play.
My current argument is to give vm_page_t an aliasing capability -
vm_alias_t's are actually linked into multiple objects and can
alias the same vm_page_t, and thus allows the VM system to maintain
cache coherency between VFS layers up to a break point (e.g. a
file fragment or a VFS device that must translate the contents
of a page, such as RAID-5 or an encryption module), and then use
a more sophisticated (and less efficient) model to bridge the
gaps - aka a cache coherency protocol aka John's 'bidirectional
IPC capability' idea.
Most of the VOP-like calls would be shifted to run through
vm_object_t and BIO (struct buf's) would be removed entirely.
So, for example, the UFS/FFS filesystem code would run mostly
through the VM system's very efficient coherency model but if
it must do something extraordinary, like truncate a file, the
more sophisticated coherency protocols (John's 'bidrectional IPC')
would be used to pass information back up into the VM system
(e.g. 'destroy these pages, dude!').
The same protocols would be used in a networked/clustered environment
to do cache coherency for mmap()'d objects (and other things) across the
network.
-Matt
:Again, I agree, but I am thinking totally in a distributed environment.
:VFS (as it is today) just doesn't work. If you rename a VM (or object)
:oriented scheme as VFS, then VFS is okay. VFS as it is allows (and
:supports) only unidirectional communication... Bzzzt, in a distributed
:environment.
:
:>
:> Yeah, a local media FS is pretty intimate with the VM system,
:> especially in the getpages/putpages area (and, if supported as
:> a direct interface instead of a layer on top of the getpages/putpages,
:> bmap). But that intimacy should be formally abstract.
:>
:But why add additional, and unneeded layers of abstraction, like the way
:that current VFS works?
:
:VFS might be good for naming (but doesn't handle the case of revocation
:of names correctly, does it?) See, there is just too much hackery necessary
:when using "VFS" for non-local systems...
:
:--
: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.
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
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?199901052236.OAA97860>