On 20 August 2017 at 01:34, Mikulas Patocka wrote:
>
> If you issue a single ioctl that takes extreme amount of time - the kernel
> warns about being blocked for extreme amount of time - what else should it
> do?
>
But as I said, it does NOT warn about being blocked if the ioctl is
issued for a S
On 15 August 2017 at 08:20, Mikulas Patocka wrote:
>
> It happens because encryption is too slow, it takes more than 120 seconds
> to clear the device. I don't know what else it should do. It is not easy
> to interrupt the operation because you would then have to deal with
> dangling bios.
>
What
Just tested the patch with kernel 4.12.6. Well it sort of worked. No
more OOM or kernel panic. Memory takeup is around ~250M on a machine
with 8G RAM. However I keep getting this:
Aug 15 04:04:10 archlinux kernel: INFO: task blkdiscard:538 blocked
for more than 120 seconds.
Aug 15 04:04:10 archlin
just a dm-crypt issue on handling multiple
bios created with next_bio (a bio chain)?
On 10 August 2017 at 07:27, Tom Yan wrote:
> 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
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 suspicious
ryptd_crypt_write_convert() /
crypt_alloc_buffer(). However, I don't really parse dm_accept_partial_bio() (or
the comment about it) so I don't really know what it actually does or how it
does it. Neither can I see it helps in reality anyway.
Here is another test case that shows the prob
ctually does or how it does it. Neither can I see it
helps in reality anyway.
Here is another test case that shows the problem:
https://ptpb.pw/BWWo.png
https://ptpb.pw/aRTE.png
Regards,
Tom Yan
> From: Tom Yan
> Sent: Monday, August 7, 2017 9:58 AM
> To: dm-devel@redhat.com
> Subject
r(). However, I don't really parse dm_accept_partial_bio() (or the com=
ment about it) so I don't really know what it actually does or how it does =
it. Neither can I see it helps in reality anyway.
Here is another test case that shows the problem:
https://ptpb.pw/BWWo.png
https://ptpb.pw/a
ave been testing on are USB devices that
does NOT support WRITE SAME or UNMAP.
Regards,
Tom Yan
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel