[stgt] stgt basic kernel interface questions

Joe Eykholt jeykholt at cisco.com
Fri Jul 9 07:48:13 CEST 2010



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



More information about the stgt mailing list