On Fri, Jun 10, 2011 at 02:48:00PM +0100, Joe Thornber wrote:
> On Fri, Jun 10, 2011 at 09:41:50AM -0400, Mikulas Patocka wrote:
> > This works if the data is directly on the partition, but it won't work on
> > the device mapper (if MD is on the device mapper, it won't work too).
> >
> > The device mapper has no function to tell where the bio is finally
> > remapped, so you can't read disk statistics for that particular disk.
>
> ok, thx
Right, you do not know which phyical device the IO may end up on,
if it passes through several stacking layers.
But even if that would be desirable in the long term,
it may not be necessary right now? [*]
Jobs on one mapping would not notice that the same physical device may
be busy via some other mapping.
But at least it would notice user (ok, non-kcopyd) IO on the same source
or destination mapping(s), which is a big improvement already, compared
with completely ignoring what is going on?
struct kcopyd_job {
...
struct dm_io_region source;
struct dm_io_region dests[...];
...
}
struct dm_io_region {
struct block_device *bdev;
...
}
struct block_device {
...
struct gendisk *bd_disk;
...
}
struct gendisk {
...
struct hd_struct part0; <--- there live the stats.
...
}
[*]
/me wildly handwaving
That could be solved, if we want to.
Add to block_device_operations:
struct gendisk * (*get_lower_level_gendisk)(struct gendisk*);
struct gendisk *appropriate_function_name(struct gendisk *d)
{
while (d->fops->get_lower_level_gendisk)
d = d->fops->get_lower_level_gendisk(d);
return d;
}
Then have some convenience functions part_stat_read_lowest_level(...).
May have come up before, probably was rejected because of uglyness?
;-)
Lars
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
