Project

General

Profile

Actions

Bug #14784

closed

Desire scsi_hba_tgtmap_scan_luns

Added by Garrett D'Amore 5 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

vioscsi (and soon more drivers) occasionally need to trigger a rescan of LUNs because some virtual HBAs can attach LUNs dynamically.

The HBA framework currently handles this somewhat obtusely by looking for a CHECK CONDITION indicating that the REPORT LUNS data has changed, and then issues a REPORT LUNS to requery the target to get the set of LUNs.

As it turns out, LUNs are also added dynamically by other kinds of SCSI targets -- such as iSCSI or fibre-channel targets on enterprise arrays, or even served directly by COMSTAR. This isn't a big deal right now because the FC and iSCSI HBAs don't use iport(9), but really they could benefit from being able to do so.

There are two problems with this:

1. That behavior is entirely undocumented.
2. Check condition situations may be consumed by the HBA itself (e.g. when doing it's own inquiries), losing this information.

It is possible to build a fake version of the check condition on a bogus scsi packet, but that is very awkward, and you're relying on that undocumented behavior. This is what vioscsi currently does.

What would be superior is to have a way to signal to the target map that it should go ahead and rescan the LUNs. A simple API:

void scsi_hba_tgtmap_scan_luns(scsi_hba_tgtmap_t *handle, char *tgt_addr).

This can have the same restrictions that other target map functions have (user or kernel context). It can also be significantly simpler since all we need to do is allocate an entry and stick it on the list that the scanning function uses. This can be done safely by checking for duplicates, to prevent an ill-behaved HBA from resubmitting the same rescan request over and over and causing unbounded memory consumption.

We have an implementation of this at RackTop, that we have used to simplify the vioscsi driver, and my forth coming "rewrite" (modernization) of pvscsi (and in the future other drivers such as hv_storvsc).

Actions #1

Updated by Electric Monk 5 months ago

  • Gerrit CR set to 2213
Actions #2

Updated by Garrett D'Amore 5 months ago

  • Status changed from New to In Progress
Actions #3

Updated by Garrett D'Amore 5 months ago

  • Status changed from In Progress to Pending RTI

Testing notes:
I’ve tested this using vioscsi and a not-yet-integrated rewrite of pvscsi. This has involved hot-plugging targets, and also, now, hot plugging a real disk (i.e. SCSI pass through on vioscsi).

Actions #4

Updated by Electric Monk 5 months ago

  • Status changed from Pending RTI to Closed
  • % Done changed from 80 to 100

git commit e302d6af529afb66d0ef5663cf940d230dc1122e

commit  e302d6af529afb66d0ef5663cf940d230dc1122e
Author: Garrett D'Amore <gdamore@racktopsystems.com>
Date:   2022-07-06T01:27:39.000Z

    14784 Desire scsi_hba_tgtmap_scan_luns
    Reviewed by: Robert Mustacchi <rm+illumos@fingolfin.org>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
    Approved by: Gordon Ross <gordon.w.ross@gmail.com>

Actions

Also available in: Atom PDF