[stgt] [PATCH 1/2] DLL backing store

[Richard Sharpe]

On Thu, Aug 21, 2008 at 12:18 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Tue, 19 Aug 2008 14:52:23 +1000
> Mark Harvey <markh794 at gmail.com> wrote:
>
>> Richard Sharpe wrote:
>> > On Sun, Aug 17, 2008 at 10:48 PM, Mark Harvey <markh794 at gmail.com> wrote:
>> >> From ea4d57fca07516c03980970cf90b937c45e3811e Mon Sep 17 00:00:00 2001
>> >> From: Mark Harvey <markh794 at gmail.com>
>> >> Date: Mon, 18 Aug 2008 15:03:21 +1000
>> >> Subject: New backing store for ssc type devices.
>> >>
>> >> Uses a double-linked list header with each block of data.
>> >>
>> >> Implement basic fixed block READ_6 & WRITE_6 OP codes.
>> >>
>> >> Still along way to go.
>> >> - Race condition on blk header between threads.
>> >
>> > Hmmm, why do you say there is a race here? Surely only one initiator
>> > can access a tape at one time, and unless you have multiple threads
>> > for the one tape, there should not be a problem here, unless I am
>> > missing something?
>> >
>>
>> It may be me that's missing something. I still have not got my head around the multi-threaded code.
>>
>> However I assume that 'multi-threaded' allows a worker thread to accept one SCSI op code.
>>
>> If the 2nd (or subsequent command) arrives during the update of the blk_header by the earlier thread, then there is a possibility of one thread using the blk_header belonging to the first thread and over writing each others data & header.
>>
>> e.g.
>> writeA -> read blk_headerX (and start to copy/build new blk_headerY)
>> writeB arrives before writeA has completed building blk_headerY
>>
>> Results is A & B writes will use the same blk_header (blk_headerX) information and over-write each others data.
>>
>> I am more then happy to be told I'm wrong.
>
> I've not looked at the code, but it sounds like you need to use
> pthread_mutex_lock/unlock.
>
> Using only one thread could be a quick fix for now.
>
>
>> But I see some simple locking process during the period of 'read header -> update new header & save in SSC header'. Then
>> allow actual write/read of any data process to complete outside the mutex/spinlock

Is there a simple mechanism to associate all CDBs for a device-LUN
with a single thread?
--
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