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? Read/Write >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 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. >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 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. Steve