[stgt] [PATCH] sg-based backing store

[Alexander Nezhinsky]

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

Then the only "inconsistent" scenario is when the device has WCE off
and we send a SYNC_CACHE to it, because we got it from the initiator.
This seems to be legal, at least as far as i understand the
sbc-2 spec on SYNC_CACHE and WCE.

So am i right saying that at least SYNC_CACHE-wise we are ok?
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html