On Wed, 22 Oct 2008 08:17:47 -0700 "Alexander Nezhinsky" <nezhinsky@xxxxxxxxx> wrote: > >> So only the device itself may be really WCE'ed. But then, if we pass through > >> the INQUIRY command and not fake the WCE bit, then we are ok. > >> We report WCE of the device and forward > >> SYNCHRONIZE_CACHE to it, everything is consistent. > >> > >> Do you suggest that i'd introduce a new device type with more > >> commands forwarded to the backing-store than sbc currently does ? > >> I would like to fix the issue. > > > > I made it clear, SCSI passthrough is not an option. So any command > > filtering (that's exactly passthrough, as I wrote in the previous > > mail) is not an option too. > > > > If you let some SCSI commands (maybe you want to let MODE SELECT pass > > too to change WCE), you need to track the state of scsi devices > > Ok, i understand your point. Although I would opt for a partial device > state tracking (when necessary) this is a much broader discussion. > Here I'd like to clarify things regarding the current sg backing store. > > It just looks to me that the current implementation almost unintentionally > handles SYNC_CACHE correctly. As a matter of fact, SYNC_CACHE > always gets to the backing store, because sbc_sync_cache() > calls bs_cmd_submit(cmd) unconditionally. > The implementation of bs_sg does not discriminate between the > commands passed to it. There is no different behavior for WRITE/READ > or SYNC_CACHE for example. Thus if there is sync_cache sent > from the initiator, we'll send it to the device. > > There could be a problem if the device had WCE on, when we reported > it off, but this is not the case as tgt always reports WCE on. Not correct. tgt enables initiators to turn off WCE with MODE SELECT. tgt also enables administrators to do so. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
