Re: [dm-devel] [bug?] "vgs" command hanging after running "targetctl clear"

2016-06-15 Thread Chris Friesen
On 06/15/2016 12:27 PM, Chris Friesen wrote: I'm running a CentOS-7 based system, so if that disqualifies me due to the amount of kernel patches please let me know. :) Anyways, I've run into some weird behaviour. I have a single system. I'm exporting an ISCSI target using targetctl. The

[dm-devel] [PATCH] multipath-tools: add patchwork info to README

2016-06-15 Thread Xose Vazquez Perez
Cc: Christophe Varoqui Cc: device-mapper development Signed-off-by: Xose Vazquez Perez --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 77b79b8..c1c53fc 100644 --- a/README +++

[dm-devel] [bug?] "vgs" command hanging after running "targetctl clear"

2016-06-15 Thread Chris Friesen
I'm running a CentOS-7 based system, so if that disqualifies me due to the amount of kernel patches please let me know. :) Anyways, I've run into some weird behaviour. I have a single system. I'm exporting an ISCSI target using targetctl. The backing store is a thinly-provisioned LVM

Re: [dm-devel] [PATCH] multipath-tools: add VIOLIN/CONCERTO ARRAY to hardware table

2016-06-15 Thread Xose Vazquez Perez
On 06/10/2016 03:56 PM, Xose Vazquez Perez wrote: > based on documentation provided by manufacturer: > https://drive.google.com/open?id=0B_B6YmEmO7cDQlMzc1BsaUxZRVU Please, DROP this patch. It's buggy. > libmultipath/hwtable.c | 19 +++ > 1 file changed, 19 insertions(+) > >

[dm-devel] [PATCH] Multipath: Remove duplicated memset() for multipathd show command.

2016-06-15 Thread Gris Ge
Problem: * The duplicated memset() wasted too much time. For example: with 5k paths, "sudo multipathd -k'show paths'" command will have at least 5k times of memset(). Reasons: * The memory passing to snprint_xxx(e.g. snprint_multipath) is already zeroed by MALLOC(). * No need to

Re: [dm-devel] [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-15 Thread Baolin Wang
On 15 June 2016 at 15:39, Herbert Xu wrote: > On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote: >> >> But that means we should divide the bulk request into 512-byte size >> requests and break up the mapped sg table for each request. Another >> hand we

Re: [dm-devel] [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-15 Thread Herbert Xu
On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote: > > But that means we should divide the bulk request into 512-byte size > requests and break up the mapped sg table for each request. Another > hand we should allocate memory for each request in crypto layer, which > dm-crypt have

Re: [dm-devel] [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-15 Thread Baolin Wang
On 15 June 2016 at 14:49, Herbert Xu wrote: > On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: >> >> After some investigation, I still think we should divide the bulk >> request from dm-crypt into small request (each one is 512bytes) if >> this algorithm

Re: [dm-devel] [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-15 Thread Herbert Xu
On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: > > After some investigation, I still think we should divide the bulk > request from dm-crypt into small request (each one is 512bytes) if > this algorithm is not support bulk mode (like CBC). We have talked > with dm-crypt >

Re: [dm-devel] [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-15 Thread Baolin Wang
Hi Herbert, On 8 June 2016 at 10:00, Baolin Wang wrote: > Hi Herbert, > > On 7 June 2016 at 22:16, Herbert Xu wrote: >> On Tue, Jun 07, 2016 at 08:17:05PM +0800, Baolin Wang wrote: >>> Now some cipher hardware engines prefer to handle bulk