Andy Grover wrote: > On 09/19/2014 04:51 PM, Alex Elsayed wrote: > >>> Not sure I follow.. How does the proposed passthrough mode prevent >>> someone from emulating OSDs, media changers, optical disks or anything >>> else in userspace with TCMU..? >>> >>> The main thing that the above comments highlight is why attempting to >>> combine the existing in-kernel emulation with a userspace backend >>> providing it's own emulation can open up a number of problems with >>> mismatched state between the two. >> >> It doesn't prevent it, but it _does_ put it in the exact same place as >> PSCSI regarding the warnings on the wiki. It means that if someone wants >> to implement (say) the optical disc or OSD CDBs, they then lose out on >> ALUA &co unless they implement it themselves - which seems unnecessary >> and painful, since those should really be disjoint. In particular, an OSD >> backed by RADOS objects could be a very nice thing indeed, _and_ could >> really benefit from ALUA. > > Some possible solutions: > > 1) The first time TCMU sees an opcode it passes it up and notes whether > it is handled or not. If it was handled then future cmds with that > opcode are passed up but not retried in the kernel. If it was not > handled then it and all future commands with that opcode are handled by > the kernel and not passed up. > > 2) Same as #1 but TCMU operates on SCSI spec granularity - e.g. handling > any SSC opcode means userspace must handle all SSC commands. > > 3) Like #2 but define opcode groupings that must all be implemented > together, independent of the specifications. > > 4) Have passthrough mode set at creation, but with more than two modes, > either grouped by SCSI spec or our own groupings. > > 5) Never pass up certain opcodes, like the ALUA ones or whatever. > > > Have a good weekend -- Andy I think 4 would probably be best, and if defining more modes is backwards- compatible then we don't really even have to decide between 2 and 3. I do think 3 is the more useful one, but it's likely also more effort to figure out a usable set than 2 would be. Also, it might be good to allow more than one grouping, and just union them. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
