Re: Linux Virtual SCSI HBAs and Virtual disks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aboo Valappil wrote:
> I implemented a new IOCTL to remove  this  scsi_host  if the user 
> process really needs to.  This removal  will first  finish all the SCSI 
> commands (With the above status results) queued on the scsi_host  (If at 
> all) and then remove the scsi_host.  Also the module unload will delete 
> all the scsi_hosts created after finishing all the commands queued with 
> the above status and sense information.

This is a valid approach, but probably more useful would be something like:
  - userspace device server or "modprobe -r" or procfs/sysfs magic or
    whatever else requests removal of a Scsi_Host (or merely of a single
    scsi_device),
  - vscsihba enters scsi_remove_host() or scsi_remove_device(),
  - SCSI core and upper layers do whatever it takes to withdraw from
    the respective I-T(-L) nexus gracefully (e.g. synchronize cache,
    unlock drive door...),
  - userspace device server handles any previously remaining commands
    and the new shutdown commands like intended,
  - SCSI core and upper layers are finished with their business,
    the respective Scsi_Host or scsi_device does not exist anymore now,
    vscsihba leaves scsi_remove_host() or scsi_remove_device(),
  - vscsihba tells userspace device server somehow that there will be
    no further requests, ever.

That way, your "virtual" device server is exposed to everything which a
"real" device server would be too when a Linux initiator shuts the
connection down. Could be interesting to testbed device servers as well
as to userspace bridges to "real" device servers.

When implemented, the "graceful shutdown" path should look almost
exactly like the opposite of the start-up path. The "hot-unplug" path
looks a little different because vscsihba has to go through that path
without assistance of the userspace server. Ideally, the "hot-unplug"
path would actually be the "graceful shutdown" path plus a few little
extra measures to account for premature absence of the device server.

[Of course, I'm saying all this without ever having designed a Linux
SCSI LLD myself, only from the background of maintaining an LLD written
by other people...]
-- 
Stefan Richter
-=====-=-=== ---= =-===
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux