[dm-devel] Re: [mauelshagen at sistina.com: sparse target]

[Heinz J . Mauelshagen]

On Mon, Dec 16, 2002 at 04:29:13PM -0600, Steve Pratt wrote:
> 
> Heinz Mauelshagen wrote:
> 
> >EVMS team (Steve or Corry are the ones to ask i guess),
> 
> >Joe mentioned that you are implementing a sparse and a bbr target
> >for device-mapper.
> 
> Yes, we are.

:)

How long do you estimate till first public code will be available ?

> 
> >I've got a couple of questions for you.
> 
> >1. Is it read-only or read-write sparse?
> 
> Read/Write

Ok.

> 
> >1b. If it's read-write sparse it must allocate storage dynamically on
>     >writes kicking of a user space allocator waiting for those writes
>     >on a table event queue, right?
> 
> No, it use the same basic COW logic as snapshotting, only there is no read.
>     Basically a device is allocated as a sparse target with a chunk size.
>     Space is reserved for a table of allocations, and as writes to
>     previously unused virtual chunks occur the next avaible real chunk is
>     allocated.  This is all done in kernel space like in snapshots.

Ah, that was the other way i had in the back of my head...

Do you stack on another target (i.e linear) to store the written chunks to ?

> 
> 
> >2. I assume that the bbr target uses preallocated and inaccessable table
>    space
>    >(inaccessable in terms of regular io queued to the bbr target) to be
>    >allocated on the fly on io error?
> 
> Correct.
> 
> >2a. If that allocation happens, do you send an event to update metadata in
>     user
>     >space in order to reflect the relocation?
> 
> No, again we use in kernel (DM) metadata writes to record the allocation.

Alright.

> 
> >2b. How do you guarantee that that update is atomic?
> 
> Locking in the kernel.

If you don't rely on any user space interaction that's pretty obvious ;)

> 
> >2b. Preallocation is fine to gain performance. Additionally you guys must
>     be
>     >planning to stack bbr onto sparse (presuming read-write sparse),
>     right?
> 
> Ow, that hurts my head.  Preallocation solves the problem of where do you
>     put it. We could stack bbr and sparse, but I don't see why.

Because you implement the mechanism for pre-allocation just once that way ?

> 
> 
> Steve
> 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen at Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-