Re: [PATCH] dm-kcopyd/dm-snap: Don't read the origin on full chunk write

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

 



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

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel


[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux