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@xxxxxxxxxxx +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-