Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?

Vladislav Bolkhovitin vst at vlnb.net
Wed Dec 14 16:09:51 CET 2005


Mike Christie wrote:
> Vladislav Bolkhovitin wrote:
> 
>> FUJITA Tomonori wrote:
>>
>>> From: Vladislav Bolkhovitin <vst at vlnb.net>
>>> Subject: Re: Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new 
>>> version of iscsi target?
>>> Date: Fri, 09 Dec 2005 18:28:58 +0300
>>>
>>>
>>>>> Also is the page cache comment in reference to us using the page 
>>>>> cache for our reads and writes or I am not sure why you wrote that 
>>>>> if you do not do it right now.
>>>>
>>>>
>>>>
>>>> Hm, at first, the page cache already used somehow in fileio dev 
>>>> handler (though, with additional mem copy). At the second, fully 
>>>> utilize the page cache is one of two major improvements that are 
>>>> pending in scst, because it is required changing the kernel, which 
>>>> until some moment try to avoid. Although I prepared what is 
>>>> necessary for that.
>>>>
>>>> The idea basically is the following. When READ operation arrives, 
>>>> pages for all requested blocks are at first searched in the page 
>>>> cache (probably, in SIRQ context, because it isn't expensive 
>>>> operation) and if all pages are found, they are referenced and the 
>>>> result will be sent to the initiator. Then the pages will be 
>>>> dereferenced (so, no pages allocation will be done at all). 
>>>> Otherwise, the missed pages will be allocated and the command will 
>>>> be rescheduled to the thread, which will read them. Then, after the 
>>>> response is sent, the pages will remain in the page cache for future 
>>>> accesses. For WRITEs the processing is the similar, the pages with 
>>>> the data will be put in the page cache.
>>>
>>>
>>>
>>> The Ardis iSCSI target code does the same thing.
>>
>>
>>
>> Perfectly. So, why don't do it on the mid-layer level where all 
>> targets can benefit from it?
>>
> 
> Any target can hook into stgt too? What is your point since neither of
> us are in mainline or even close given the scsi guy's veiwpoint on where 
> to do reads and writes?

My point is to show one of the benefits of the kernel side 
implementation. Any target driver (of scst or stgt, doesn't matter) 
should benefit from it. Obviously, there is no point to overcomplicate 
any target driver with the functions of the the mid-level.

Vlad


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel



More information about the stgt mailing list