Bill Studenmund writes:
> On Tue, 15 Jun 1999, Chuck Silvers wrote:
> 
> > here's some info on UBC, how it works, what changes are needed for a
> > filesystem to support it, etc.
> 
> [snip]
> 
> > with UBC, regular file data lives only in the page cache, and is read
> > and written directly from the page cache without going thru the buffer
> > cache.  read() and write() use a new kind of non-wired kernel mapping
> > to access the page cache pages when copying the data to the user's buffer.
> > (eventually this copy can be optimized away using UVM's loaning feature.)
> 
> [snip]
> 
> > in addition, the VOP_READ() and VOP_WRITE() interfaces of a filesystem
> > need to be changed to use ubc_alloc() and ubc_release() instead of the
> > current getblk() and brelse() to get access to file data in memory.
> > ubc_alloc() is like getblk() in that it returns a virtual address
> > where you can access the file data, but it's different in several ways,
> > most importantly that the UBC mapping isn't wired and so accessing it
> > may generate page faults, and those page faults can even fail to be
> > resolved successfully in the case of a device i/o error.  so UBC mappings
> > can only be accessed via fault-safe methods like uiomove().
> 
> Somewhat related question: how would we handle stacked filesystems which
> cached data? i.e. a compression layer which wants to cache the
> uncompressed version of the file.

I'm not trying address stackable filesystems at this point.
they'll have the same problems in UBC that they do currently.
doing cache coherency for stackable filesystems is lot more work
and there's not time to do that for the next release.

-Chuck