9119d9
From d8140487d0af54c4017e1d06a7ee5c676fad0a83 Mon Sep 17 00:00:00 2001
9119d9
Message-Id: <d8140487d0af54c4017e1d06a7ee5c676fad0a83@dist-git>
9119d9
From: John Ferlan <jferlan@redhat.com>
9119d9
Date: Thu, 20 Nov 2014 10:42:52 -0500
9119d9
Subject: [PATCH] storage: Fix issue finding LU's when block doesn't exist
9119d9
9119d9
https://bugzilla.redhat.com/show_bug.cgi?id=1152382
9119d9
9119d9
Fix a problem in the getBlockDevice and processLU where retval initialized
9119d9
to zero causing some failures to erroneously continue through to the
9119d9
virStorageBackendSCSINewLun with an attempt to find a path for "/dev/(null)".
9119d9
This would fail approximately 10 seconds later with debug message:
9119d9
9119d9
virStorageBackendSCSINewLun:203 :
9119d9
     No stable path found for '/dev/(null)' in '/dev/disk/by-path'
9119d9
9119d9
The root cause of the issue is for many /sys/bus/scsi/devices/<lun path>
9119d9
there is no "block*" device found for the vHBA's, where "<lun path>" are
9119d9
the various paths created for the vHBA, such as "17:0:0:0", "17:0:1:0",
9119d9
"17:0:2:0", "17:0:3:0", etc.  If the block device isn't found, then the
9119d9
directory should just be ignored rather than attempting to process it.
9119d9
9119d9
The bug was that in getBlockDevice the assumption was "block" would exist
9119d9
and either getNewStyleBlockDevice or getOldStyleBlockDevice would fill in
9119d9
@block_device. However, if 'block*' doesn't exist, then the code returned
9119d9
NULL for block_device *and* a good (zero) retval value.  This caused the
9119d9
processLU code to attempt the virStorageBackendSCSINewLun which failed
9119d9
"at some point in time" in the future.
9119d9
9119d9
After this change - on test system the refresh-pool didn't have a noticable
9119d9
pause of about 20 seconds - it completed within a second since no longer
9119d9
was there an attempt/need to find "/dev/(null)".
9119d9
9119d9
Additionally, the virStorageBackendSCSIFindLU's shouldn't be declaring
9119d9
found unless the processLU actually returns success. This will be
9119d9
important in the followup patch which relies on whether a LU was found.
9119d9
9119d9
(cherry picked from commit 20870417322f7090d32e31cde864a2f916f55181)
9119d9
9119d9
Conflicts:
9119d9
	src/storage/storage_backend_scsi.c
9119d9
9119d9
   Downstream doesn't have mkletzan's curly brace check, so there was
9119d9
   one place in the module where they were removed, but this code adds
9119d9
   them back in because it's doing a VIR_DEBUG on getBlockDevice failure
9119d9
   (see upstream e7a1da8aeb945e4d54693dd7a580caf94fec8a11)
9119d9
9119d9
Signed-off-by: John Ferlan <jferlan@redhat.com>
9119d9
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
9119d9
---
9119d9
 src/storage/storage_backend_scsi.c | 15 +++++++--------
9119d9
 1 file changed, 7 insertions(+), 8 deletions(-)
9119d9
9119d9
diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c
9119d9
index 3f61610..367216a 100644
9119d9
--- a/src/storage/storage_backend_scsi.c
9119d9
+++ b/src/storage/storage_backend_scsi.c
9119d9
@@ -322,7 +322,7 @@ getBlockDevice(uint32_t host,
9119d9
     char *lun_path = NULL;
9119d9
     DIR *lun_dir = NULL;
9119d9
     struct dirent *lun_dirent = NULL;
9119d9
-    int retval = 0;
9119d9
+    int retval = -1;
9119d9
     int direrr;
9119d9
 
9119d9
     if (virAsprintf(&lun_path, "/sys/bus/scsi/devices/%u:%u:%u:%u",
9119d9
@@ -334,7 +334,6 @@ getBlockDevice(uint32_t host,
9119d9
         virReportSystemError(errno,
9119d9
                              _("Failed to opendir sysfs path '%s'"),
9119d9
                              lun_path);
9119d9
-        retval = -1;
9119d9
         goto out;
9119d9
     }
9119d9
 
9119d9
@@ -369,7 +368,7 @@ processLU(virStoragePoolObjPtr pool,
9119d9
           uint32_t lun)
9119d9
 {
9119d9
     char *type_path = NULL;
9119d9
-    int retval = 0;
9119d9
+    int retval = -1;
9119d9
     int device_type;
9119d9
     char *block_device = NULL;
9119d9
 
9119d9
@@ -380,7 +379,6 @@ processLU(virStoragePoolObjPtr pool,
9119d9
         virReportError(VIR_ERR_INTERNAL_ERROR,
9119d9
                        _("Failed to determine if %u:%u:%u:%u is a Direct-Access LUN"),
9119d9
                        host, bus, target, lun);
9119d9
-        retval = -1;
9119d9
         goto out;
9119d9
     }
9119d9
 
9119d9
@@ -398,6 +396,7 @@ processLU(virStoragePoolObjPtr pool,
9119d9
               host, bus, target, lun);
9119d9
 
9119d9
     if (getBlockDevice(host, bus, target, lun, &block_device) < 0) {
9119d9
+        VIR_DEBUG("Failed to find block device for this LUN");
9119d9
         goto out;
9119d9
     }
9119d9
 
9119d9
@@ -406,9 +405,9 @@ processLU(virStoragePoolObjPtr pool,
9119d9
                                     block_device) < 0) {
9119d9
         VIR_DEBUG("Failed to create new storage volume for %u:%u:%u:%u",
9119d9
                   host, bus, target, lun);
9119d9
-        retval = -1;
9119d9
         goto out;
9119d9
     }
9119d9
+    retval = 0;
9119d9
 
9119d9
     VIR_DEBUG("Created new storage volume for %u:%u:%u:%u successfully",
9119d9
               host, bus, target, lun);
9119d9
@@ -453,10 +452,10 @@ virStorageBackendSCSIFindLUs(virStoragePoolObjPtr pool,
9119d9
             continue;
9119d9
         }
9119d9
 
9119d9
-        found = true;
9119d9
-        VIR_DEBUG("Found LU '%s'", lun_dirent->d_name);
9119d9
+        VIR_DEBUG("Found possible LU '%s'", lun_dirent->d_name);
9119d9
 
9119d9
-        processLU(pool, scanhost, bus, target, lun);
9119d9
+        if (processLU(pool, scanhost, bus, target, lun) == 0)
9119d9
+            found = true;
9119d9
     }
9119d9
 
9119d9
     if (!found)
9119d9
-- 
9119d9
2.1.3
9119d9