All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20200903225424.331f1d94@suse.de>

diff --git a/a/1.txt b/N1/1.txt
index 9305f69..28f7ee5 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -32,7 +32,7 @@ On Thu, 3 Sep 2020 10:36:58 -0500, Michael Christie wrote:
 > 
 > So is the answer to my question a maybe but it probably will never happen?
 
-A src=dest XCOPY? I think it's just as likely as a cross device XCOPY.
+A srcŢst XCOPY? I think it's just as likely as a cross device XCOPY.
 The UUID collision error is probably unlikely to be triggered because:
 - XCOPY is a pretty exotic SCSI command mostly used by ESXi
 - Users may already provide a vpd_unit_serial with enough unique
@@ -60,7 +60,7 @@ reasons for RFC are:
 - I've tested this with libiscsi's iscsi-dd (-x) and test suite, but not
   against the ESXi initiator yet.
 
-> For example, I create 2 tcmu devices. They both point to the same real device. Then export dev1 through target port1 and dev2 through target port2. Each tcmu device would then have it’s own data/cmd ring and locking, so you do not hit those perf issues. I do this for perf testing. I don’t think that type of thing is common or ever done, so I think the patch would be ok if that is a concern and it’s better than possible data corruption.
+> For example, I create 2 tcmu devices. They both point to the same real device. Then export dev1 through target port1 and dev2 through target port2. Each tcmu device would then have it’s own data/cmd ring and locking, so you do not hit those perf issues. I do this for perf testing. I don’t think that type of thing is common or ever done, so I think the patch would be ok if that is a concern and it’s better than possible data corruption.
 > 
 > Code wise it looks ok to me.
 
diff --git a/a/content_digest b/N1/content_digest
index 77f7fd1..fcaa266 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,7 +4,7 @@
  "ref\07F596A9A-2116-4BA8-8A32-E98EDE996D8C@oracle.com\0"
  "From\0David Disseldorp <ddiss@suse.de>\0"
  "Subject\0Re: [RFC PATCH] scsi: target: detect XCOPY NAA descriptor conflicts\0"
- "Date\0Thu, 3 Sep 2020 22:54:24 +0200\0"
+ "Date\0Thu, 03 Sep 2020 20:54:24 +0000\0"
  "To\0Michael Christie <michael.christie@oracle.com>\0"
  "Cc\0target-devel@vger.kernel.org"
  " linux-scsi@vger.kernel.org\0"
@@ -44,7 +44,7 @@
  "> \n"
  "> So is the answer to my question a maybe but it probably will never happen?\n"
  "\n"
- "A src=dest XCOPY? I think it's just as likely as a cross device XCOPY.\n"
+ "A src\305\242st XCOPY? I think it's just as likely as a cross device XCOPY.\n"
  "The UUID collision error is probably unlikely to be triggered because:\n"
  "- XCOPY is a pretty exotic SCSI command mostly used by ESXi\n"
  "- Users may already provide a vpd_unit_serial with enough unique\n"
@@ -72,7 +72,7 @@
  "- I've tested this with libiscsi's iscsi-dd (-x) and test suite, but not\n"
  "  against the ESXi initiator yet.\n"
  "\n"
- "> For example, I create 2 tcmu devices. They both point to the same real device. Then export dev1 through target port1 and dev2 through target port2. Each tcmu device would then have it\342\200\231s own data/cmd ring and locking, so you do not hit those perf issues. I do this for perf testing. I don\342\200\231t think that type of thing is common or ever done, so I think the patch would be ok if that is a concern and it\342\200\231s better than possible data corruption.\n"
+ "> For example, I create 2 tcmu devices. They both point to the same real device. Then export dev1 through target port1 and dev2 through target port2. Each tcmu device would then have it\303\242\342\202\254\342\204\242s own data/cmd ring and locking, so you do not hit those perf issues. I do this for perf testing. I don\303\242\342\202\254\342\204\242t think that type of thing is common or ever done, so I think the patch would be ok if that is a concern and it\303\242\342\202\254\342\204\242s better than possible data corruption.\n"
  "> \n"
  "> Code wise it looks ok to me.\n"
  "\n"
@@ -80,4 +80,4 @@
  "\n"
  Cheers, David
 
-6dcac343bac1bcdd89a42d8ea93e51f0a5a7f01de031c199b391c04a022882c4
+f5cf55522a2821f10ad4f7da2434887a260e5ac57204a8d1bb061ef96165b103

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.