On Sun, 2017-08-13 at 22:47 -0400, Mikulas Patocka wrote:
>
> On Wed, 9 Aug 2017, h...@lst.de wrote:
>
> > Does commit 615d22a51c04856efe62af6e1d5b450aaf5cc2c0
> > "block: Fix __blkdev_issue_zeroout loop" fix the issue for you?
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> >
On Wed, 9 Aug 2017, h...@lst.de wrote:
> Does commit 615d22a51c04856efe62af6e1d5b450aaf5cc2c0
> "block: Fix __blkdev_issue_zeroout loop" fix the issue for you?
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
I think that patch is
Never mind, I guess I was wrong, coz bio_add_page() is always called
with "offset" = 0 here, so:
offset == bv->bv_offset + bv->bv_len
is never matched. Hence,
if (bio->bi_vcnt >= bio->bi_max_vecs)
return 0;
will trigger the if-break.
So maybe this is after all just a dm-crypt issue on
I haven't really tested but I was aware of the commit before I send my
last email. It doesn't seem relevant to be honest, because it doesn't
change the fact that the inner loop wil only end if the whole request
has been looped over. So still one big bio.
There are a few things that seem
On 08/09/2017 03:38 PM, h...@lst.de wrote:
Does commit 615d22a51c04856efe62af6e1d5b450aaf5cc2c0
"block: Fix __blkdev_issue_zeroout loop" fix the issue for you?
I crashed the 4.13-rc4 with the test above (blkdiscard -z on dm-crypt
dev). Unfortunately I hadn't have my VM configured properly so
Hi again,
I think I have sort of identified the problem. It appears to me that both the
block layer and dm-crypt is defected on handling this.
First of all, check out the "fallback" zero out implementation, which is used
in this case, here:
(Sorry for the spam. Having hard time moving the thread from
outlook.com to gmail.com for linux-block. Please reply to this, thank
you.)
Hi again,
I think I have sort of identified the problem. It appears to me that
both the block layer and dm-crypt is defected on handling this.
First of all,
Hi again,
I think I have sort of identified the problem. It appears to me that both t=
he block layer and dm-crypt is defected on handling this.
First of all, check out the "fallback" zero out implementation, which is us=
ed in this case, here:
