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.

Take care,

Bill