Re: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6

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

 



On Wed, 2012-07-18 at 11:00 -0500, Anthony Liguori wrote:
> On 07/18/2012 10:53 AM, Christoph Hellwig wrote:
> > On Wed, Jul 18, 2012 at 08:42:21AM -0500, Anthony Liguori wrote:
> >>
> >> If you add support for a new command, you need to provide userspace
> >> a way to disable this command.  If you change what gets reported for
> >> VPD, you need to provide userspace a way to make VPD look like what
> >> it did in a previous version.
> >>
> >> Basically, you need to be able to make a TCM device behave 100% the
> >> same as it did in an older version of the kernel.
> >>
> >> This is unique to virtualization due to live migration.  If you
> >> migrate from a 3.6 kernel to a 3.8 kernel, you need to make sure
> >> that the 3.8 kernel's TCM device behaves exactly like the 3.6 kernel
> >> because the guest that is interacting with it does not realize that
> >> live migration happened.
> >
> > I don't think these strict live migration rules apply to SCSI targets.
> >
> > Real life storage systems get new features and different behaviour with
> > firmware upgrades all the time, and SCSI initiators deal with that just
> > fine.  I don't see any reason to be more picky just because we're
> > virtualized.
> 
> But would this happen while a system is running live?

Of course: Think about the consequences: you want to upgrade one array
on your SAN.  You definitely don't want to shut down your entire data
centre to achieve it.  In place upgrades on running SANs have been
common in enterprise environments for a while.

> I agree that in general, SCSI targets don't need this, but I'm pretty sure that 
> if a guest probes for a command, you migrate to an old version, and that command 
> is no longer there, badness will ensue.

What command are we talking about?  Operation of initiators is usually
just READ and WRITE.  So perhaps we might have inline UNMAP ... but the
world wouldn't come to an end even if the latter stopped working.

Most of the complex SCSI stuff is done at start of day; it's actually
only then we'd notice things like changes in INQUIRY strings or mode
pages.

Failover, which is what you're talking about, requires reinstatement of
all the operating parameters of the source/target system, but that's not
wholly the responsibility of the storage system ...

James

> It's different when you're talking about a reboot happening or a 
> disconnect/reconnect due to firmware upgrade.  The OS would naturally be 
> reprobing in this case.



--
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