On Wed, 8 Dec 1999 09:07:51 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> said:
>> I have discovered in the usual way (looking at the code) that it seems
>> the 2.2 kernel doesn't support mmap on devices. In the do_mmap function
>> (mm/mmap.c:247), ENODEV is returned if the file doesn't support the mmap
>> operation.
> Yes. This should finally be a thing of the past soon: one of the issues is
> that the mmap() code requires the page cache, and the page cache didn't
> use to handle the case of large devices correctly, and as such couldn't be
> used - and raw devices for that reason had their very own special code.
There is one big problem with this: software raid.
We had this come up before but it never really reached a resolution.
To work efficiently, soft raid 5 wants access to all cached data for
its parity calculations. Ingo has already been talking about putting
the page cache overlay buffers back into the buffer cache hash lists
specifically for that purpose.
As soon as we have <4k-blocksize buffers pinned in this way in the
page cache, we cannot freely relocate those buffers to be page-aligned
with respect to their physical location.
The layering-violation of the soft raid code already means that you
cannot safely run journaling or swap on top of raid 1 or raid 5. One
way or another, we need to define the right semantics for IO: does it
always go throught the buffer cache, linked into the hash lists and
findable by the raid code, or is ll_rw_block the sole API?
Raid 5 is going to have a hard time anyway continuing its cache
snooping if the proposals to add a kiobuf-based alternative interface
to the request layer pan out.
--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/