What everyone is side-stepping is that the interface between the drivers
and the buffer cache is incestuous -- this prevents folks from building
async I/O based FS's on Linux. The solution is not a simple one -- the
drivers and buffer cache interface needs to be changed to elimnate these
dependencies so.
Jeff
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Mon, 01 Nov 1999 02:13:32 -0700, "Jeff V. Merkey"
> <jmerkey@timpanogas.com> said:
>
> > Actually, if you guys would design something a littler newer than circa
> > 1973 for your buffer cache design, things would be easier. The buffer
> > cache acts this way becuase it is based on a PRIMITIVE design that's not
> > far off from the textbook description found in "UNIX: a practical
> > implementation." Novell was doing mirroring and distributed mirroring
> > since about 1984. We are just trying to get linux closer to the 1990's.
>
> The buffer cache is not intended to provide primary support for doing
> advanced IO control. If you want to do mirroring, then fine, do it at a
> different layer. We have 2 open source journaling implementations for
> Linux right now which work above the buffer cache, and software raid
> working below it. In 2.3, _all_ file write activity bypasses the buffer
> cache entirely. The fact that the process performing write-behind in
> 2.3 happens to be bdflush in buffer.c is almost incidental: it could
> just as easily be done at the VFS layer. Ext3 journaling on 2.2 also
> bypasses the buffer cache to perform IO.
>
> The buffer cache isn't the place to provide mirroring. Do it above or
> below. Why wouldn't a low-level mirroring driver below ll_rw_block do
> what you want? Even if it didn't, you could achieve the same effect
> within the page cache using specialised write-back routines.
>
> The main lack in this area is one you pointed out in an earlier email
> --- the lack of any way for the VM to request that the owner of an
> arbitrary page of the page cache or buffer cache release that page
> prevents easy memory balancing between cache consumers. We're
> discussing ways to deal with that in 2.3/2.5.
>
> --Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/