Mike,
>> In the first place, if it's an LVM-only issue, we should fix it only
>> for device-mapper devices. If this is the right way to fix it,
>> possibly the way to do that would be to change DM calls to
>> blk_queue_max_write_same_sectors() to only set the max sectors to
>> more than 0 if and
Hi Martin,
Those patches works well and this issue not happened again, thanks.
On 2019/1/5 1:59, Martin Wilck wrote:
> Hi Chongyun, Ben, all,
>
> this patch set addresses the points where I can see that handling of
> shutdown signals may be delayed, as discussed previously. Quoting my
> previous
On Sat, Jan 26 2019 at 6:17am -0500,
John Dorminy wrote:
> Hi. I have read a bit of DM code and spent an hour reviewing this... I
> didn't get to the point of knowing what the right fix for the problem
> is, and I may have a wrong understanding, but I have two thoughts
> about the patch:
>
> I
ping.
On 1/24/2019 8:25 PM, John Dorminy wrote:
Resending as plain text, apologies.
On Thu, Jan 24, 2019 at 1:23 PM John Dorminy wrote:
Adding dm-devel since it involves LVM.
On Thu, Jan 24, 2019 at 1:14 PM Zhang Xiaoxu wrote:
If the lvm is stacked by different logical_block_size disks,
Hi， Thanks for your reply.
BUG_ON is because the 'bio_iovec(bio).bv_len' not same with 'sdp->sector_size'.
Just as below reproducer, If the 'golden' is stacked by disks
'sda'(logical_block_size=512)
and 'sdb'(logical_block_size=4096), call 'blkdev_issue_write_same' on it will
BUG_ON because
of
