On Wed, Feb 2, 2011 at 9:47 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > When I mentioned allocation bitmap before, I meant simply a bitmap > specifying whether the block exists, that would let us avoid looking for > an object in the parent image. In its simplest form, you would mark the > image read-only, then generate the bitmap once. > ... > Mainly I'm interested in feedback on the simple layering use-case... So my thought with the bitmap was that it might make more sense for rbd to maintain a bitmap specifying whether the child has overwritten the parent block device. Then when doing a read in the parent region, rbd defaults to reading the parent block device unless the bitmap says the child has overwritten it. This is reasonably fast in terms of failed reads and such: assuming the bitmap is kept in-memory, you don't need to do multiple attempts to do a read, and if the client wants to zero a block, or overwrites a block and then deletes it, there's no concern about preventing inappropriate fall-through to the parent since the bitmap still has that block set as overwritten. The other advantage to something like this is that it could allow overwriting at a finer level than the size of the child's blocks. For instance, you might store in 4MB chunks, but that's a bit large for some things that are going to commonly change between images like config files. So with a bitmap with, say, 1KB resolution you could change a config file and have rbd read the block from the parent and then plug in the 1KB containing the config file that the child overwrote. This doesn't require too much space: storing a 1KB-granularity bitmap for a 1GB image only requires 1MB. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
