Great, I will do that. Thank you for all your help!
On Wed, Apr 24, 2019 at 6:22 PM Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
On Wed, Apr 24 2019 at 5:27pm -0400,
Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
>
> On Wed, Apr 24 2019 at 10:46am -0400,
> Ryan Norwood <ryan.p.norwood@xxxxxxxxx> wrote:
>
> > On Wed, Apr 24, 2019 at 9:08 AM Ryan Norwood <[1]ryan.p.norwood@xxxxxxxxx>
> > wrote:
> >
> > Thank you for your help.
> > You are correct, it appears that the problem occurs when there is a RAID
> > 5 or RAID 50 volume beneath VDO.
> > NAME KNAME RA SIZE ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC
> > RQ-SIZE SCHED WSAME
> > sdh
> > sdh 128 977.5G 0 512 0 512 512 128
> > deadline 0B
> > +-sed6
> > dm-6 128 977.5G 0 512 0 512 512 128
> > 0B
> > +-md127
> > md127 12288 5.7T 0 1048576 6291456 512 512 128
> > 0B
> > +-vdo_data
> > dm-17 128 5.7T 0 1048576 6291456 512 512 128
> > 0B
> > +-vdo
> > dm-18 128 57.3T 0 4096 4096 4096 4096 128
> > 0B
<snip>
> > /sys/block/dm-18/queue/max_hw_sectors_kb:4
> > /sys/block/dm-18/queue/max_sectors_kb:4
These are getting set as a side-effect of MD raid imposing the need for
merge_bvec (in the context of RHEL7.x only, not upstream) otherwise it
goes conservative and forces the IO to be contrained to a single page,
please see:
drivers/md/dm-table.c:dm_set_device_limits() at the end:
/*
* Check if merge fn is supported.
* If not we'll force DM to use PAGE_SIZE or
* smaller I/O, just to be safe.
*/
if (dm_queue_merge_is_compulsory(q) && !ti->type->merge)
blk_limits_max_hw_sectors(limits,
(unsigned int) (PAGE_SIZE >> 9));
With MD raid in the IO stack, dm_queue_merge_is_compulsory() will return
true, so the VDO target not providing ti->type->merge causes this issue.
Please file a BZ at bugzilla.redhat.com against VDO and I'll continue to
work with the VDO developers to get this fixed for you for RHEL7.5, etc.
Thanks,
Mike
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
