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
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
+++
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
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(+)
>
>
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
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
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
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
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
>
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
10 matches
Mail list logo