[stgt] [PATCH] sg-based backing store

Alexander Nezhinsky nezhinsky at gmail.com
Fri Oct 17 08:59:53 CEST 2008


On Tue, Oct 14, 2008 at 9:17 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Tue, 14 Oct 2008 09:30:00 -0700
> "Alexander Nezhinsky" <nezhinsky at gmail.com> wrote:

>> When we perform the measurements involving the null device, there is zero
>> penalty on random accesses. Thus performance improvements with
>> sequential access are indicative for any types of load.
>
> The performance improvement is really great but only 0.01 percent of
> iSCSI people would say, "Supporting only scsi devices is ok for
> performance improvement." It's unacceptable for the majority. Flexible
> device management is a must.

Never said it was intended for majority. Perhaps for a minority but the
one with clearly identifiable needs. And the performance measurements
tried to show those needs are met, not implied anything else.

> What we really need to do is improving Linux AIO suuport, which
> benefits not only tgt but everyone.

What about introducing a new module (or expanding the existing stgt kernel
infrastructure), so that it supports an sg-like interface but translates scsi
commands into kernel aio api calls?

This will delegate to kernel the data-path part of the target (which was always
considered the right thing to do), it is protocol independent and breaks
dependency on the AIO and eventfd implementation etc.

I also thought about it because it can allow introducing a bunch of special
optimizations, which i can discuss separately.

What do u think? If we agree that it is a plausible direction, i am
ready to start
writing a prototype.

>> This bs_sg implementation uses DIO at all times. I guess we don't have
>> to care about WCE because when we send a status to initiator, the data is
>> not merely written to cache (well, it is not), it has been actually sent to the
>> i/o device and acked by it.
>
> Not correct. Using sg's DIO means nothing for this issue. DIO just
> represents a way to move data between kernel and user space.
>
> For example, we enables WCE by default so initiators send
> SYNCHRONIZE_CACHE and this sg code ignores it. If a scsi device
> enables WCE, you are in trouble.

In the case of SG when DIO is used, i guess that an I/O completion
delivered to the user space always means that I/O reached the device,
it can't be queued anywhere in the kernel.
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.

Please, answer how you envision a desired solution. You did not respond
to my suggestion about an additional api between the device-type and
backing-store. 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.
--
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