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

hi Stephen,

i'm happy that we agree :-) Let me point out those couple of arguments
that i believe were not sufficiently explained previously. All in one, i
do not think there is any big problems:

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

> *That* is the problem. I agree with you that doing the hash is going
> to be good for raid-5 performance. However, doing so is going to lock
> down hashed buffers in memory in an alignment which does not match the
> physical layout of the buffers. You cannot have a buffer hashed
> twice: once you have that buffer hashed in the page cache based on
> virtual offset, you cannot then hash it into the page cache again
> based on physical blocknr.

yes, i'm aware of this problem, this is why i said: 'the RAID code doesnt
want to own blocks for a long time'. Ie. at exactly the places where i did
the insert_into_queues() in the small patch, we likely need a lookup for
existing blocks & waiting for it if it's used & destroy it after it's used
(atomically). Since the RAID5 code goes through the device in a big linear
scan, there is no danger that it will 'sit on' some block forever. In
fact, it will almost never 'sit on' any block. It can also happen during
degraded-mode operation that such an alias is created, and this can be
resolved similarly.

the good news is that this only happens during 'establishment' of the
pagecache. Ie. dbench numbers do not care the least, the cost is not for
an already established mapping. (establishing a mapping is costy anyway,
and likely involves lowlevel fs activity)

also, in the normal, non-RAID case there will be no additional
synchronization. (except in the metadata case which right now is a bit
buggy or triggers a bug and is thus turned off.)

does this explain my intentions? Can you see any problems with this?

> The question is about whether or not all mappings of buffers should be
> hashed or not. The advantage of doing so is that raid-5 can find data
> in the caches more easily: the disadvantage is that it makes decent
> semantics for page-cached block devices that much harder.

yes, my point is to hash all blocks, conceptually. This is not the dreaded
'alias' issue, because we are not really aliasing something into itself,
this is a one-time hierarchy thing between the pagecache and buffer-cache.
The buffer-cache is the 'physical index', the pagecache is the 'logical
index'. We just were a bit lazy about maintaining the physical index.

> [...] The question is how
> raid-5 will snoop data in general, given that current 2.3 filesystems
> don't hash their buffers and future filesystems may not even use
> buffer_heads in their caching; [...]

even current filesystems cache data 'privately', extensively. Just think
of inodes. This is not a problem at all - if nobody establishes a mapping
without listening to the rules of the physical index.

> [...] and given that the page-alignment of
> buffer heads for block device IO will be incompatible with the hashing
> of all page-cached buffer_heads (we'd have buffer_heads for the same
> disk block hanging off both the filesystem's inode and the block
> device inode).

yep, this is not a problem either. (I'll also try to optimize this a bit
for the sake of RAID5 (nothing else will care too much), if a buffer-cache
block is there already, then instead of waiting & destroying it we can
copy it's contents into the pagecache block, if the pagecache is doing a
readin.)

-- 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.048 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site