lkml.org 
[lkml]   [1999]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mmap on a device returns ENODEV

On Fri, 10 Dec 1999, Stephen C. Tweedie wrote:

> 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.

for christ's sake, this is not a RAID5 problem at all. Yes, RAID5 wants to
snoop clean block cache state (even if in the pagecache), but it does in
no way interfer in the typical case. It does 'hold up' blocks for a short
period of time during resynchronization, but you are free to free/relocate
those buffers once they got clean. This is nothing new.

> 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

there is no goddam layering violation. The RAID5 code accesses the buffer
(and in the future the page) cache only from system call context, in a
well-defined way. If by layering violation you mean 'nobody else can ever
look up your goddam buffer', then yes. But thats a bad cache design IMO.

note that even today we already wait for 'users' to go away for freshly
allocated blocks, check out unmap_underlying_metadata(). You cannot
generally assume that a block is not used by some other subsystem.

i dont know Stephen what your problem is. I thought we agreed on that by
defining clean 'dont touch' semantics in the buffer-cache the RAID code
and journalling code can do it's thing just fine. I do believe that we can
use the (thank god much simplified) buffer-cache to synchronize access to
block devices. This is not really hard to do, and i'll do it (soon). It
has other advantages too, apart from RAID5 which alone might not bother
people.

-- mingo


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.183 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site