diff for duplicates of <1490362271.2516.4.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index f89c560..0c5203a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,12 +1,10 @@ On Fri, 2017-03-24 at 13:46 +0100, Jinpu Wang wrote: > Our IBNBD project was started 3 years ago based on our need for Cloud > Computing, NVMeOF is a bit younger. -> - IBNBD is one of our components, part of our software defined storage so= -lution. +> - IBNBD is one of our components, part of our software defined storage solution. > - As I listed in features, IBNBD has it's own features ->=20 -> We're planning to look more into NVMeOF, but it's not a replacement for I= -BNBD. +> +> We're planning to look more into NVMeOF, but it's not a replacement for IBNBD. Hello Jack, Danil and Roman, @@ -15,8 +13,7 @@ Boston to present this work at the Vault conference. However, my understanding of IBNBD is that this driver has several shortcomings neither NVMeOF nor iSER nor SRP have: * Doesn't scale in terms of number of CPUs submitting I/O. The graphs shown - during the Vault talk clearly illustrate this. This is probably the resul= -t + during the Vault talk clearly illustrate this. This is probably the result of sharing a data structure across all client CPUs, maybe the bitmap that tracks which parts of the target buffer space are in use. * Supports IB but none of the other RDMA transports (RoCE / iWARP). @@ -29,11 +26,10 @@ The fact that IBNBD only needs to messages per I/O is an advantage it has today over SRP but not over NVMeOF nor over iSER. The upstream initiator drivers for the latter two protocols already support inline data. -Another question I have is whether integration with multipathd is supported= -? +Another question I have is whether integration with multipathd is supported? If multipathd tries to run scsi_id against an IBNBD client device that will fail. Thanks, -Bart.= +Bart. diff --git a/a/content_digest b/N1/content_digest index 277d991..dc67a2e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,12 +19,10 @@ "On Fri, 2017-03-24 at 13:46 +0100, Jinpu Wang wrote:\n" "> Our IBNBD project was started 3 years ago based on our need for Cloud\n" "> Computing, NVMeOF is a bit younger.\n" - "> - IBNBD is one of our components, part of our software defined storage so=\n" - "lution.\n" + "> - IBNBD is one of our components, part of our software defined storage solution.\n" "> - As I listed in features, IBNBD has it's own features\n" - ">=20\n" - "> We're planning to look more into NVMeOF, but it's not a replacement for I=\n" - "BNBD.\n" + "> \n" + "> We're planning to look more into NVMeOF, but it's not a replacement for IBNBD.\n" "\n" "Hello Jack, Danil and Roman,\n" "\n" @@ -33,8 +31,7 @@ "understanding of IBNBD is that this driver has several shortcomings neither\n" "NVMeOF nor iSER nor SRP have:\n" "* Doesn't scale in terms of number of CPUs submitting I/O. The graphs shown\n" - " during the Vault talk clearly illustrate this. This is probably the resul=\n" - "t\n" + " during the Vault talk clearly illustrate this. This is probably the result\n" " of sharing a data structure across all client CPUs, maybe the bitmap that\n" " tracks which parts of the target buffer space are in use.\n" "* Supports IB but none of the other RDMA transports (RoCE / iWARP).\n" @@ -47,13 +44,12 @@ "today over SRP but not over NVMeOF nor over iSER. The upstream initiator\n" "drivers for the latter two protocols already support inline data.\n" "\n" - "Another question I have is whether integration with multipathd is supported=\n" - "?\n" + "Another question I have is whether integration with multipathd is supported?\n" "If multipathd tries to run scsi_id against an IBNBD client device that will\n" "fail.\n" "\n" "Thanks,\n" "\n" - Bart.= + Bart. -e79cca2a43ceb598c106cef29eb10768c6cd86d12bae7d71c6f64f8119488358 +33c736ff31241f9b4753129db731168421104ae5b3270e80cbd0de1249d0eb26
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.