[uml-devel] About COW & filesystems

[uml-devel] About COW & filesystems

[James McMechan]

I saw a comment about updateing loopback to do the
COW file functions, some of Jeff Dike's new COW stuff
seems to indicate that he was looking at something like that
though the last status I remember was don't use it yet :/
some of it seems to have been removed from more recent UMLs

If you want to hack on it I would suggest looking at the device mapper
as I seem to remember comments about the loop device being a poor
example to follow, and not being maintained well, and the new device
mapper already has examples of feeding requests back into the block
queue, using DM you could split the request for COW data and
backing data to seperate ubd devices, note that it would be nice to
have more ubd devices when doing this...
Even better, if you hack it well it would also work on host kernels,
well 2.6+ host kernels but DM appears to be the wave of the
future, and COW files on real devices would be sweet.

********

Regarding the new COW V3 format

Jeff I saw your comments about
1) Alignment field in header - to align bitmap & data
2) mmapping option - to mmap the data and bitmap
3) cow format option - to provide for alternate layouts
4) moved backing file to end of header - this puts all the fixed length
stuff first
5) fixed rounding bug - not sure which rounding but this was
6) updated header to fixed lengths - well mostly the time was still a
local fomat
7) d option - to prevent treating a COW file as a COW file (a later
option I think)

********

Commentary on features

1) Alignment -- the previous problems with alignment were
due to reading a header that was not a exact multiple of sector size
this is why it would not work on raw devices, it dumped out
trying to read the header not the data, since it checks first if it is a
cow header and quits on a read error it could not even be the backing
file the alignment of the bitmap and data sectors was not a problem but
fixing that would be nice to have, also I think that putting the real
offsets
rather then a alignment value would make more sense if it is aligned
wrong
it can't be easily changed.

2) mmaping option -- my problem has always been the reverse
my UMLs ran out of address space even when just mmapping
the COW bitmap, I can picture paging in sections of the data by
mmap, but as proposed I would expect to run out of address
space on my first ubd of ~2-4GiB since I have tried (using my
previous patch set) a 64TiB array (sparse) I would expect to
use all of memory for the mmap in short order. I am not sure that
mmapping is faster than pread/pwrite which I was using earlier, I
expect that both would be faster than the seek and then
read+write that currently is in use.

3) cow format option - the ISAM files that have been proposed as
alternatives to the sparse COW files that V2 uses for DOS format
filesystems which don't do spare files well, I seem to remember ~3
different formats for different puropses some of which would require
different layous for the header ... ick, and I have thought it would be
easier to just use new V4..6 for example as the COW version instead
besides I don't seem to remember anyone showing code, I just made
a few fragments as tests.

4) moving backing file to end of structure -- I think I may have
suggested this it makes it much easier for me at least to read the
hex dumps on the COW file, also zeroing the backing file array
make it easier to read, I seemed to get mostly 'Z' in my dumps
which is ok but \0 is nicer, I have slab posioning turned on.

5) fixed rounding bug - I am not sure which of the rounding bugs
this refers to, I think it is the calculate cowbit map size but there
was
also the one about passing 2 words of the bitmap between
ubd_kern and ubd_user which would walk off the end of the mmap
I was working on haveing the bitmap only read from the user side
since I think it makes the ubd_kern driver much clearer

6) update header to fixed lengths - another portability bit I may
have suggested, I think that the time should be converted also.

7) d option - this is another approach that should work when
using raw devices in addation to its commented purpose of
letting UML read a COW file as a plain file.

********

Other featues I seem to remember coding examples for

A) having C/H/S in the header - I would like to be able to have
other partition layouts so that real disk images can be used.

B) treating the COW stuff as private_data to the ubd_kern.c
so that it can stack, and with this we can push the COW
option parsing over to _user side and then the _user side
can also be used as libaray for uml_moo, one implementation
is of course safer in that fixes don't need to match in two
codebases.

C) removing the limitations on 8 ubd devices this gets
rather messy if the COW info (fds, bitmap, is not private to the _user
side

D) create COW file by seek rather then writing lots of zeros

E) I have a preference for making the COW layer look like
other linux file functions i.e. open,close,[p]read,[p]write.
I prefer the pread/pwrite since in halves the number of system
calls by not needing a seek for every read/write

F) paged COW bitmap - I run out of memory when I do
strange things like wanting a COW file on >512GiB files
so I did a paged bitmap

G) alignment - the header needs to be padded one of the
reason was that my test versions had both length and offsets
for the backing file name, COW bitmap, and data area
if this is done they can be placed in any order and
extra fields can be added to the header without breaking
the exisiting code, the other option is to use something like
the tagged headers of e.g. zip files, well one of those DOS
tar replacements.

H) Alignment 2 - another reason for offsets is that when
problems are discoved like the offset calculation the
code to read the old format must still be present in its
errornous form to allow for reading the previous COW
files otherwise the corrected calculation will index to
the wrong part of the file producing a off by 1 error
on the sector address of each data sector and having
all the COW sector adresses off by 1 will be very
corrupt as some sectors, those in the COW file will
have that off by 1 and those in the backing file won't
... ick ....

I) the fast bitmap operations - the bitmap test/set/clear
functions can be done with shift (<<,>>) and &,| this
code is both faster and smaller then the current *,/,%
code

********

Stuff that I have not done but would be willing to code

I) paged COW mmap - if you really think that mmap is
much more efficient than pread I will try out a paged
version so I don't run out of memory

II) paged data mmap - and I am willing to do the same
for the data if you think it would help alot

III) one of the ISAM files as a example if someone
would be willing to use it for a while. One simple
example is ok but there has not been alot of call
for ISAM on the list, and I hate writing brand new
dead code....

IV) updated moo program to convert several layers
of COW file into one
e.g. COWA,COWB,COWC,backing to produce
COWA,backing2
also to update C/H/S for a new partition layout
also change alignment of COW file for different
requirements I like offsets rather than a single
alignment value so that the file elements can be
put in any order and have gaps of desired sizes.

V) add in a sector size option so that we can
play like CDROMs and that funny sectored
hardware, Zip disk maybe?

********

Jeff you had said that you would like it in small parts

I would offer converting to COW_open,close,read,write
first with the private_data so ubd_kern gets cleaned up.
then converting to dynamic disk allocation, stackable
COW files get quite easy with private_data it can just
recurse using the private_data to find the next layer,
and since it does not require static information from
ubd_kern it can stack, my notes indicate I was running
25 deep COW file stacks.

Or perhaps the conversion to external COW
version files, cow_v1.[ch] etc.which makes plugging
in new versions easier e.g. V3 & ISAM, I seem to
recall testing with the fops proposal, and one where
a index was used to select which read/write routines
were used, fops was more the linux kernal style though.

Paged mmap for the bitmap and data could occur in any
order with the other work

The faster bitops are a tranparent replacement.

This is somewhat backwards in that it stacks the COW
file under the ubd device, but this is pretty much how it
has always been done and once the ubd_kern side is
cleaned up putting a equivalent on top via DM should
not make things too complex, I seem to remember
booting from DM or worse yet loopback is a pain.
Then later once DM is working nicely we can drop
the COW layer under ubd easily by just replacing
the COW_open/close/read/write with the normal
open/close/read/write functions and let DM do
all the hard work, alas not in the 2.4 roadmap,
though it does seem like something that may get
backported...

Sorry to be so long but I haven't done much on
UML but some work on booting of the ThinkNIC
distribution on UML, and way to much fighting
with windows at work.

James McMechan


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. 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

Re: [uml-devel] About COW & filesystems

[Matt Zimmerman]

On Tue, Oct 28, 2003 at 01:34:10AM -0800, James McMechan wrote:

> Even better, if you hack it well it would also work on host kernels, well
> 2.6+ host kernels but DM appears to be the wave of the future, and COW
> files on real devices would be sweet.

DM is available and actively maintained on 2.4 as well (LVM2 and EVMS 2.x
use it there).  They already implement snapshots (COW) using device-mapper;
the only difference is that they use a different on-disk metadata format to
store the bitmap.

> This is somewhat backwards in that it stacks the COW file under the ubd
> device, but this is pretty much how it has always been done and once the
> ubd_kern side is cleaned up putting a equivalent on top via DM should not
> make things too complex, I seem to remember booting from DM or worse yet
> loopback is a pain.  Then later once DM is working nicely we can drop the
> COW layer under ubd easily by just replacing the COW_open/close/read/write
> with the normal open/close/read/write functions and let DM do all the hard
> work, alas not in the 2.4 roadmap, though it does seem like something that
> may get backported...

Booting from DM is not bad; there is an ioctl interface to get the physical
block addresses to give to the boot loader, and a patch for LILO to use it.
I don't know whether grub or any non-i386 bootloaders have support yet.

-- 
 - mdz


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

Re: [uml-devel] About COW & filesystems

[Jeff Dike]

James_McMechan@hotmail.com said:
> 1) Alignment -- the previous problems with alignment were due to
> reading a header that was not a exact multiple of sector size this is
> why it would not work on raw devices, it dumped out trying to read the
> header not the data, since it checks first if it is a cow header and
> quits on a read error it could not even be the backing file the
> alignment of the bitmap and data sectors was not a problem but fixing
> that would be nice to have, also I think that putting the real offsets
> rather then a alignment value would make more sense if it is aligned
> wrong it can't be easily changed.

The alignment was really needed for mmap.  The data needed to be page aligned
in order to be mmapped.  I aligned everything else more or less for the
hell of it.  It does have the advantage that there is now some extra room
after the header that can be used for new stuff without necessarily needing
a new version of the format.

> 2) mmaping option -- my problem has always been the reverse my UMLs
> ran out of address space even when just mmapping the COW bitmap, I can
> picture paging in sections of the data by mmap, but as proposed I
> would expect to run out of address space on my first ubd of ~2-4GiB
> since I have tried (using my previous patch set) a 64TiB array
> (sparse) I would expect to use all of memory for the mmap in short
> order. I am not sure that mmapping is faster than pread/pwrite which I
> was using earlier, I expect that both would be faster than the seek
> and then read+write that currently is in use.

First, the mmap option is used to map pages from the device directly into
UML physical memory.  So, address space isn't a problem here because it's
already allocated.

Second, 64 bit machines have lots of address space.

As for speed, using mmap trades a tlb flush for data copying.  Here, a kernel
build is about the same speed either way.  It would be a win for very 
write-dominated loads, though.  The real reason for doing it was to save
memory on the host.

pread/pwrite would be good.  I'm not too interested in reducing the system call
count, but it has other advantages.  It eliminates a bit of code.  It also
makes the seek and read/write atomic, which isn't an issue now, but it may
become one in the future.

> 3) cow format option - the ISAM files that have been proposed as
> alternatives to the sparse COW files that V2 uses for DOS format
> filesystems which don't do spare files well, I seem to remember ~3
> different formats for different puropses some of which would require
> different layous for the header ... ick, and I have thought it would
> be easier to just use new V4..6 for example as the COW version instead
> besides I don't seem to remember anyone showing code, I just made a
> few fragments as tests. 

It would be good to have at least one working alternative so we can see what
changes are needed.  Then we can split the header between stuff that all
formats will need and stuff that's format zero-specific.  That should make
it easier to add new formats.  Also, a non-sparse format will make it easier
to put COW files on physical devices, where you want to use the space 
efficiently.

> 5) fixed rounding bug - I am not sure which of the rounding bugs this
> refers to, I think it is the calculate cowbit map size 

It is.

> but there was
> also the one about passing 2 words of the bitmap between ubd_kern and
> ubd_user which would walk off the end of the mmap I was working on
> haveing the bitmap only read from the user side since I think it makes
> the ubd_kern driver much clearer 

Ummm, I don't remember that one.  The problem is that the first word would
be the last one in the bitmap, and the second word would be the one following
that?

> 6) update header to fixed lengths - another portability bit I may have
> suggested, I think that the time should be converted also. 

I switched some of the fields - others I wasn't sure about so I left them
alone.

> A) having C/H/S in the header - I would like to be able to have other
> partition layouts so that real disk images can be used. 

I don't like this in the COW header.  If you want CHS, you want it for all
devices, COWed or not.  So some way of specifying geometry is needed that
doesn't involve the COW header.

> B) treating the COW stuff as private_data to the ubd_kern.c so that it
> can stack, and with this we can push the COW option parsing over to
> _user side and then the _user side can also be used as libaray for
> uml_moo, one implementation is of course safer in that fixes don't
> need to match in two codebases. 

The COW stuff needs to be removed from the ubd driver totally, and turned into
a separate driver.  This is why I didn't merge your COW layering stuff.  The
real way to do that is
	cow0=cow0_file,/dev/cow1 cow1=cow1_file,backing_file

> D) create COW file by seek rather then writing lots of zeros 

This is done, and has been for a while.

> F) paged COW bitmap - I run out of memory when I do strange things
> like wanting a COW file on >512GiB files so I did a paged bitmap 

Yeah.  Don't know what to do about this.  One wacko idea I was pondering was
(in skas mode), making multiple kernel address spaces which are the same, except
they have different sections of the COW bitmap mapped.  So, rather than mapping
the bitmap in and out, you switch to the address space that has the section
you need.

> G) alignment - the header needs to be padded one of the reason was
> that my test versions had both length and offsets for the backing file
> name, COW bitmap, and data area if this is done they can be placed in
> any order and extra fields can be added to the header without breaking
> the exisiting code, the other option is to use something like the
> tagged headers of e.g. zip files, well one of those DOS tar
> replacements. 

This sounds over-engineered to me.  I'd rather leave things more constrained
as they are now, and make people have to justify new things that don't fit.

> I would offer converting to COW_open,close,read,write first with the
> private_data so ubd_kern gets cleaned up. then converting to dynamic
> disk allocation, stackable COW files get quite easy with private_data
> it can just recurse using the private_data to find the next layer, and
> since it does not require static information from ubd_kern it can
> stack, my notes indicate I was running 25 deep COW file stacks. 

I'd like the separate COW driver.  The ubd driver is messy enough as it is,
and I'd just like the COW stuff out of there.

> Or perhaps the conversion to external COW version files, cow_v1.[ch]
> etc.which makes plugging in new versions easier e.g. V3 & ISAM, I seem
> to recall testing with the fops proposal, and one where a index was
> used to select which read/write routines were used, fops was more the
> linux kernal style though. 

A working non-sparse COW file format would be useful.

> Paged mmap for the bitmap and data could occur in any order with the
> other work

That would be interesting.  I think that qualifies as research and 
experimentation at this point.

> The faster bitops are a tranparent replacement.

Yeah, although I don't think it makes much difference overall.

				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

Re: [uml-devel] About COW & filesystems

[James McMechan]

> James_McMechan@hotmail.com said:
> > 1) Alignment -- the previous problems with alignment were due to
>
> The alignment was really needed for mmap.  The data needed to be page
aligned
> in order to be mmapped.  I aligned everything else more or less for
the
> hell of it.  It does have the advantage that there is now some extra
room
> after the header that can be used for new stuff without necessarily
needing
> a new version of the format.

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, the pad size can actually be
different,
and the prefered natural size for read/mmap can also be different and we
might
want to set both at runtime a pad of 512 for raw devices and 64K for
natural size
since the read/mmap would likely gain

>
> > 2) mmaping option -- my problem has always been the reverse my UMLs
>
> First, the mmap option is used to map pages from the device directly
into
> UML physical memory.  So, address space isn't a problem here because
it's
> already allocated.

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?

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

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

>
> Second, 64 bit machines have lots of address space.
>
Yes that will be nice but I expect that even 5 years from now 32bit
systems
will still be quite common, and I don't have a 64bit system yet :(

> As for speed, using mmap trades a tlb flush for data copying.  Here, a
kernel
> build is about the same speed either way.  It would be a win for very
> write-dominated loads, though.  The real reason for doing it was to
save
> memory on the host.

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

> pread/pwrite would be good.  I'm not too interested in reducing the
system call
> count, but it has other advantages.  It eliminates a bit of code.  It
also
> makes the seek and read/write atomic, which isn't an issue now, but it
may
> become one in the future.

I also like the look since it does exactly what we want.

> > 3) cow format option - the ISAM files that have been proposed as
>
> It would be good to have at least one working alternative so we can
see what
> changes are needed.  Then we can split the header between stuff that
all
> formats will need and stuff that's format zero-specific.  That should
make
> it easier to add new formats.  Also, a non-sparse format will make it
easier
> to put COW files on physical devices, where you want to use the space
> efficiently.

I am willing put in one of the stupid ones, I think you could gain on
physical
devices only if you were running something like LVM which allows
resizing
or were using a device that was smaller than the backing device + map
which will fail a write it you keep using it, that of course is very
bad.

> > 5) fixed rounding bug - I am not sure which of the rounding bugs
this
> > refers to, I think it is the calculate cowbit map size
>
> It is.
>
> > but there was
> > also the one about passing 2 words of the bitmap between ubd_kern
and
> > ubd_user which would walk off the end of the mmap I was working on
> > haveing the bitmap only read from the user side since I think it
makes
> > the ubd_kern driver much clearer
>
> Ummm, I don't remember that one.  The problem is that the first word
would
> be the last one in the bitmap, and the second word would be the one
following
> that?

Yes that one, I would have to recheck what I thought was wrong,
and I could also be wrong myself :)

> > 6) update header to fixed lengths - another portability bit I may
have
> > suggested, I think that the time should be converted also.
>
> I switched some of the fields - others I wasn't sure about so I left
them
> alone.

Yes, I did regard it as progress but thought that time should be changed
too.

> > A) having C/H/S in the header - I would like to be able to have
other
> > partition layouts so that real disk images can be used.
>
> I don't like this in the COW header.  If you want CHS, you want it for
all
> devices, COWed or not.  So some way of specifying geometry is needed
that
> doesn't involve the COW header.

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

> > B) treating the COW stuff as private_data to the ubd_kern.c so that
it
> > can stack, and with this we can push the COW option parsing over to
> > _user side and then the _user side can also be used as libaray for
> > uml_moo, one implementation is of course safer in that fixes don't
> > need to match in two codebases.
>
> The COW stuff needs to be removed from the ubd driver totally, and
turned into
> a separate driver.  This is why I didn't merge your COW layering
stuff.  The
> real way to do that is
> cow0=cow0_file,/dev/cow1 cow1=cow1_file,backing_file

I would think it would be easier to remove it, if it was not so tightly
bound
also are you sure you want to remove it, the layer above ubd should be
DM
based and would be the user inside of the UML setting up COW
What we have now is a system feature under ubd  that does not
require that the user inside set it up, and is instead setup by the user
outside of the UML at runtime.
<lead balloon>
If you want to get rid of the COW feature under the ubd.
We could just delete it and use the DM functional equivialent from
inside
the UML.
</lead balloon>

> > D) create COW file by seek rather then writing lots of zeros
>
> This is done, and has been for a while.

Sorry, I was checking my old info and was not sure it had made it in

> > F) paged COW bitmap - I run out of memory when I do strange things
> > like wanting a COW file on >512GiB files so I did a paged bitmap
>
> Yeah.  Don't know what to do about this.  One wacko idea I was
pondering was
> (in skas mode), making multiple kernel address spaces which are the
same, except
> they have different sections of the COW bitmap mapped.  So, rather
than mapping
> the bitmap in and out, you switch to the address space that has the
section
> you need.

Not so wacko, I had the same idea but what a pain and tt would still
need another
way.  I was not mmapping I emulated it with a dirty flag and
pread/pwrite since I
was not sure about mmaping into the UML address space without mangleing
your
address spaces, I think I could have MAP_FIXED but pread/pwrite was safe

> > G) alignment - the header needs to be padded one of the reason was
> > that my test versions had both length and offsets for the backing
file
> > name, COW bitmap, and data area if this is done they can be placed
in
> > any order and extra fields can be added to the header without
breaking
> > the exisiting code, the other option is to use something like the
> > tagged headers of e.g. zip files, well one of those DOS tar
> > replacements.
>
> This sounds over-engineered to me.  I'd rather leave things more
constrained
> as they are now, and make people have to justify new things that don't
fit.

Yes tagged headers seemed that way to me also.  The length offset pairs
I was using make the degenerate cases easier

> > I would offer converting to COW_open,close,read,write first with the
> > private_data so ubd_kern gets cleaned up. then converting to dynamic
> > disk allocation, stackable COW files get quite easy with
private_data
> > it can just recurse using the private_data to find the next layer,
and
> > since it does not require static information from ubd_kern it can
> > stack, my notes indicate I was running 25 deep COW file stacks.
>
> I'd like the separate COW driver.  The ubd driver is messy enough as
it is,
> and I'd just like the COW stuff out of there.

Well above ubd we can use DM from inside the UML but outside of the UML
I still want to be able to set up COW files at the system level.
Matt Zimmerman said that DM is in 2.4 which I had somehow missed and
that
the DM snapshot feature could be used in place of COW

> > Or perhaps the conversion to external COW version files, cow_v1.[ch]
> > etc.which makes plugging in new versions easier e.g. V3 & ISAM, I
seem
> > to recall testing with the fops proposal, and one where a index was
> > used to select which read/write routines were used, fops was more
the
> > linux kernal style though.
>
> A working non-sparse COW file format would be useful.

I am willing to do a stupid one.

> > Paged mmap for the bitmap and data could occur in any order with the
> > other work
>
> That would be interesting.  I think that qualifies as research and
> experimentation at this point.

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

> > The faster bitops are a tranparent replacement.
>
> Yeah, although I don't think it makes much difference overall.

Well not a huge amount, but I am an old programmer and still
like my utilites in the classic forms.
Especially stuff on the common/fast paths


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

Re: [uml-devel] About COW & filesystems

[Matt Zimmerman]

On Wed, Oct 29, 2003 at 06:16:18AM -0800, James McMechan wrote:

> Well above ubd we can use DM from inside the UML but outside of the UML
> I still want to be able to set up COW files at the system level.
> Matt Zimmerman said that DM is in 2.4 which I had somehow missed and
> that
> the DM snapshot feature could be used in place of COW

No, I said it was available...it is not in 2.4 stock, but a 2.4 patch is
actively maintained; I use it on many systems.  It might not be infeasible
for it to be included in a later 2.4, but I don't track that sort of thing.

-- 
 - mdz


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

Re: [uml-devel] About COW & filesystems

[Steve Schnepp]

On Wed, Oct 29, 2003 at 06:16:18AM -0800, James McMechan wrote:
> [Plenty interesting stuff about the future of COW]

I did a kernel module to support user space loop devices. [ actually 
any userspace block device ]

The idea is that you open a /dev/ulb[a-z] and the kernel module connects
it to /dev/ulc[0-26] (major/minor are assigned automatically by the
kernel)

Then a user-space helper reads /dev/ulc0 for commands & data, and
reads/writes somewhere (usually in a file), and then writes back the
result to /dev/ulc0. For now it's heavily 2.4.x oriented...

The code isn't in a really good shape (lots of hardcoded values)
But, since i don't have much spare time i decided to publish it here in
case of someone wants to have a look at it. The code should be almost
self-explaining.

I should be able to resume working on it soon, but anyway... your
feedback is very welcome. ( i'm not a good C hacker, and i *do* like to
improve myself )

URL: http://snide.free.fr/uldd/

	Steve

-- 
GPG public key available from http://snide.free.fr/gpg/snide.free.fr.asc
   Or by email to "snide at free.fr" with "send key pub" as subject
   Fingerprint: 19D7 12ED 5A37 4F29 8FDA  19B0 6DFD 3A54 A753 EA6F 


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

Re: [uml-devel] About COW & filesystems

[Jeff Dike]

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