Re: [uml-devel] About COW & filesystems

[Jeff Dike <jdike@addtoit.com>]

James_McMechan@hotmail.com said:
> Yes, but I will argue that having the offsets directly in the header
> rather than the __u32 alignment; would seem to make more sense, the
> offsets are what are needed to compute where in the file to read/mmap

As far as calculating offsets, the information content is the same.  Putting
offsets in there strikes me as being a step in the direction of turning the
COW format into some general, self-describing thing, which I don't want.

The alignment field describes the requirement, which an offset field wouldn't,
so it seems better from a documentation point of view.

> I may be missunderstanding this works, it mmaps in from the device and
> then copies to/from the uml buffer, rather than reading/writing from
> the uml buffer?
>
> I think we can't mmap the pages from the device to the buffer address?

Yes, we can, and that's exactly what ubd=mmap does. 

> The read might have the wrong model since any writes to the just read
> buffer would be via mmap be copied back to the device. MAP_PRIVATE
> notes that it is unspecified if writes to the mmaped area will appear
> in the mmaped area, and might end up with SEGV on NORESERVE 

If the buffer wasn't mapped before, then it is written out to the file before
being mapped in again.  The mapping is done with MAP_SHARED.

> Write would have the same soft of problem in that the mmap should
> occur before the data is copied into the buffer not when the ubd
> driver is called 

Again, if the buffer was changed before the map happened, it is written out
first.

> Save memory on host seems like a good reason., I don't see where write
> gains though 

I'm not sure how well the block layer insulates the driver from a flood of
little writes, so that may have been a bogus reason.  But, if you can, within
a fixed amount of memory, cause the driver to do continuous writes, then
mapping is a win because the writes don't touch the host kernel any more.

> Actually it just seemed logical to put it in there and for those that
> don't need COW use a degenerate header e.g. no bitmap/no data area/
> backing file is written to, or no bitmap/no backing file/data area is
> the disk image 

My claim is that a need for geometry is totally independent of whether you're
using COW.  So, introducing a geometry needs to be somewhere else.  If we stick
it in the COW header, someone is going to say that they need geometry, and
they have a good reason that they can't use COW.  So, we need to come up with
something else, and then the geometry in the COW header is useless.

> It was interesting, the bookkeeping was a hassle but not too hard
> Testing it was a bit of work though 

This is basically the same problem that the VM system solves.  So, I would
look at presenting the COW bitmap to the VM system as virtual memory or a file,
and have it deal with swapping it in and out.  It may be impossible because
you can't make high level read-in-a-file-page calls from the driver because of
the locks that are already held, but I think it's worth looking at.

				Jeff



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel