[dm-devel] [PATCH] dm-kcopyd/dm-snap: Don't read the origin on full chunk write
Joe Thornber
thornber at redhat.com
Mon Jun 20 10:03:13 UTC 2011
On Mon, Jun 20, 2011 at 11:51:37AM +0200, Milan Broz wrote:
> On 06/20/2011 10:09 AM, Joe Thornber wrote:
> For the nack - I do not get it.
> Joe, please can you explain the reasons?
You know the size of the bio when you submit it. So you're saying to
kcopyd, do this copy, except if it's a particular size, then don't,
just issue the io. I don't see from Mikulas' description why kcopyd
needs to be involved in this.
For instance here's how multisnap handles it:
if (io_covers_block(pool, bio)) {
/* no copy needed, since all data is going to change */
m->bio = bio;
m->bi_end_io = bio->bi_end_io;
m->bi_private = bio->bi_private;
bio->bi_end_io = overwrite_complete;
bio->bi_private = m;
remap_and_issue(pool, bio, data_dest);
} else {
/* use kcopyd */
struct dm_io_region from, to;
from.bdev = pool->pool_dev;
from.sector = data_origin * pool->sectors_per_block;
from.count = pool->sectors_per_block;
to.bdev = pool->pool_dev;
to.sector = data_dest * pool->sectors_per_block;
to.count = pool->sectors_per_block;
r = dm_kcopyd_copy(pool->copier, &from, 1, &to,
0, copy_complete, m);
if (r < 0) {
mempool_free(m, pool->mapping_pool);
printk(KERN_ALERT "dm_kcopyd_copy() failed");
cell_error(cell);
}
}
I don't see why we want to wait for a context switch to kcopyd in
order to issue an io.
If this is about avoiding having to hook the bio endio function then
why use kcopyd rather than dm-io? (I'm not advocating this, just
asking the question).
- Joe
More information about the dm-devel
mailing list