Subject: Re: UBC info
To: Chuck Silvers <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/15/1999 13:29:09
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.
> 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.)
> 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.