On 11/19/2014 03:52 PM, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1152382
Fix a couple of fc_host SCSI refresh pool issues. The first patch I found
while working on the second.
It turns out the existing logic to handle 'retval' wasn't correct. Using
a default of zero, resulted in a couple of cases where success was returned
when it shouldn't have been. The one that caused the issues was when the
search of the /sys/bus/scsi/devices/ tree found a new vHBA related device
and then "assumed" that the 'block' device would be found in the
directory.
That assumption resulted in a 10 second pause in virStorageBackendStablePath
failing to find a stable path to the device "/dev/(null)" because the
getBlockDevice returned zero and a NULL block_device and the processLU
code only failed when the return was < 0. The processLU code had similar
issues with retval processing which are also fixed.
The second patch provides a mechanism to attempt to fill the pool of a
libvirt created VPORT_CREATE'd vHBA. The creation takes some time for the
udev callback mechanism to find and configure. By adding a thread to
attempt to retry to find the LU's (with any luck) after the udev processing
has had time to do something means a subsequent 'vol-list' on the pool may
actually find a volume without needing to attempt a 'pool-refresh' again.
It's too bad the udev mechanism didn't provide a way to indicate it has
completed setting up a specific device.
John Ferlan (2):
storage: Fix issue finding LU's when block doesn't exist
storage: Add thread to refresh for createVport
src/storage/storage_backend_scsi.c | 147 ++++++++++++++++++++++++++++++++-----
1 file changed, 128 insertions(+), 19 deletions(-)
Pushed - thanks for the review
John