On 7/8/10 10:29 PM, FUJITA Tomonori wrote: > On Mon, 05 Jul 2010 12:08:48 -0700 > Joe Eykholt<jeykholt at cisco.com> wrote: > >> Even if tgtd has read the pages and the LLD could tell, >> it wouldn't know they've made it safely to backing store. > > I'm not sure what you mean. tgtd doesn't write data to disk. It's responsible for the getting it written and for the safety of the data, though, isn't it? > When scsi_tgt_cmd_done calls scsi_unmap_user_pages (via queue_work), > we start to commit dirty pages to disk; __bio_unmap_user set pages > dirty. When the dirty bit of all the pages is cleared, the data is > committed safely. LLDs could check it, I think. If the write cache of > backing store is enabled, we more tricks though. Would that work for all backing store alternatives or just the default of writing to a file via mmap? I think a lot of systems clear the dirty bit when the writes start so they can detect further writes and then re-write the pages if they change while the write is in progress. If they don't, they'll miss writes that happen between the time the page starts out to disk and the I/O completes. I'm not up on all the backing stores tgtd supports. I think it's better if there's an explicit message from user to kernel to say that the data is safe and the response can be sent (or alternatively a separate call to write the data before the send_response call). This hurts latency but helps correctness and reliability. Regards, 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 |