[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.

>I've got a couple of questions for you.

>1. Is it read-only or read-write sparse?


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

>2. I assume that the bbr target uses preallocated and inaccessable table
   >(inaccessable in terms of regular io queued to the bbr target) to be
   >allocated on the fly on io error?


>2a. If that allocation happens, do you send an event to update metadata in
    >space in order to reflect the relocation?

No, again we use in kernel (DM) metadata writes to record the allocation.

>2b. How do you guarantee that that update is atomic?

Locking in the kernel.

>2b. Preallocation is fine to gain performance. Additionally you guys must
    >planning to stack bbr onto sparse (presuming read-write sparse),

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]