On 7/3/10 3:52 AM, FUJITA Tomonori wrote: > On Tue, 29 Jun 2010 09:22:12 -0700 > Joe Eykholt<jeykholt at cisco.com> wrote: > >>>> My specific question at this point deals with how the kernel >>>> knows the status of a WRITE command. >>>> >>>> My guess is that for WRITEs, the user-kernel interactions are: >>>> >>>> 1. TGT_KEVENT_CMD_REQ - kernel presents command to tgtd. >>>> 2. TGT_UEVENT_CMD_RSP - tgtd gives buffer address to kernel >>>> - send XFER_RDY >>>> - kernel fills in buffer >>>> 3. TGT_KEVENT_CMD_DONE - kernel indicates write data in buffer >>>> >>>> .... then, what tells the kernel it's safe to send the response? >>>> If we do it between 2 and 3, then the data isn't really safe yet. >>>> Is there another TGT_UEVENT_CMD_RSP? >>> >>> You mean that the data might not be committed to disk persistently? >> >> Yes. If the system were to crash just after the response was sent, >> the data might be lost. >> >> So, it seems we should modify the interactions to have one to >> say "get the data" between 1 and 2, or something like that. > > Adding an interaction between kernel and user space increases latency. Sad but true. There's no way around it that I can see. > scsi_cmnd includes the information about all the pages so the llds > can see if the data is committed or not? Even if tgtd has read the pages and the LLD could tell, it wouldn't know they've made it safely to backing store. We need to set up an explicit interaction to indicate that. Joe -- 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 |