[uml-user] Re: [uml-devel] Dynamic remount with variable COW stacking/merging needed, support for snapshot repilication

[BlaisorBlade <bla...@ya...>]

Alle 09:20, domenica 18 gennaio 2004, James W McMechan ha scritto:

> The types of mmaping I think might be needed:

> no mmap in use -- for when mmap does not
> work some fs do not mmap well

> index mmap -- like now only the index/bitmap
> is mmaped uses a fair amount of address space

> full mmap -- map in both the index/bitmap and
> the data, uses a huge amount of address space

> paged index -- map in a (few) pages of the
> index at a time, I have run with one page nicely

> paged data -- map in a (few) pages of the data
> at a time, I am not sure that this is helpful?

If I've correctly understood what Jeff explains, this would be very useful to 
reduce memory consumption.

> The problem I see with mmaping is that in order
> to mmap properly I need to kmalloc a buffer
> of the right size first, and then mmap on top of
> the buffer, so that the kernel does not try to
> use the space that is mmaped for other purposes
> outside of the ubd_user/cow_user functions
> which it would be free to do if it is not kmalloc'ed
> and then if it tries to read/write that address space
> the _user function would be using the mmaped
> area not the kernel memory, or when the kernel
> overwrites the index/bitmap with kernel data
> Ick the mind boggles

Ok, I've checked and physmem_subst_mapping does exactly this (even if I don't 
see a real reason for which kmalloc should reserve the correct space; maybe 
this is the bug).

> The problem I see with the ubd=mmap is that
> it does not have a failure path for a
> non-page-aligned data sector, it looks like it
> just drops it, this would I think occur mostly
> on metadata updates, 2.4.23-1um was where
> I was looking, and I could be wrong, but if it
> does I would expect massive data corruption

In fact ubd=mmap has data corruption. If you have seen why, post *this only* 
to Jeff Dike (he needed several reports to start thinking mmap was buggy). I 
say *this only* because this mail was quite long and a bit hard to read.
Also, there is an user (I'm going to ask him whether he uses ubd=mmap) which 
reports some problems (I'm forwarding his message to you).

However, I've seen the missing failure path, but comparing with 2.4.20-6um( 
the latest patch I had available on my HD without ubd=mmap) it seems that 
mmap is just not used. Also, mmap_fd is called by prepare_request, which does 
nothing if alignment is wrong, while the actual write is anyhow done in 
do_io. And I'm sure of this, since the return value of a failing mmap_fd is 
the same as when ubd=mmap is not active (from mmap_fd):

        if(!ubd_do_mmap)
                return(-1);

        /* The buffer must be page aligned */
        if(((unsigned long) req->buffer % UBD_MMAP_BLOCK_SIZE) != 0)
                return(-1);


> Oh yes as a side note 2.6.0 and 2.4.25pre
> have the fix for Oops on the host kernel
> when reading /dev/shm with hostfs so if
> that was bothering you the 2.6 or next
> 2.4 kernel should help.

Yes, I saw it. Thanks!

-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
EOSIGN