Re: Suggestion for Linux 2.3

Ingo Molnar (
Tue, 7 Jan 1997 09:46:00 +0100 (MET)

On Mon, 6 Jan 1997, David S. Miller wrote:

> Date: Mon, 6 Jan 1997 17:23:01 -0600 (CST)
> From: "Daniel G. Linder" <>
> Anyone want to work on this for Linux? I don't have the time to be
> a lead person, but this looks like it would integrate well with the
> MD driver (Multi Disk)... Might be a big step for ext2 -- anything
> going on with that project?
> I would like to see full logging and journaling added to ext2 before
> we allow such a scheme.

part of our RAID1, RAID4 and RAID5 code [we've announced it not so long
ago on linux-raid] are kernel system threads that do nontrivial/abstract
IO operations like RAID5 writes (which are a series of coordinated IO
operations) or RAID5 error recovery [redirecting and retrying IO
requests]. Once we have implemented this in a sufficiently clean way [the
Linux way of caching VM and blocks is affected], journal or transaction
based filesystems should be a breeze :)

The only open issue here is the dualness of Linux caching: on one side
an (inode,offset) based page cache, and a (dev,blocknr) block cache. Cache
elements in the VM cache do not show up in the block cache. Since any
nontrivial IO system like the RAID stuff is not only a 'block provider'
but a 'block requester' too, we have to do all things twice all things
twice. [for example, first we have to look wether a cache element is in
the page cache, then in the block cache ... yuck imho]

What we need for this particular application is a 'uniform cache
interface'. Or the total extinction of the buffer cache (which is imho not
possible due to other VM-neutral physical blocks like superblocks or
filesystem metadata in general).

somehow it would be cool to have the VM cache folded into the buffer cache
... without extra overhead ... [asking the impossible :)] ... thus we
could query the buffer cache for everything.

just have thrown in the problem here, maybe you guys have already ideas
lying around :)

-- mingo