[Ksummit-2008-discuss] Kernel Summit Request for Discussion: The Future of Target mode and Cloud storage on Linux

[Nicholas A. Bellinger]

On Wed, 2008-08-20 at 20:48 -0500, James Bottomley wrote:
> On Wed, 2008-08-20 at 18:20 -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2008-08-20 at 18:06 -0700, Greg KH wrote:
> > > On Wed, Aug 20, 2008 at 06:06:52PM -0700, Nicholas A. Bellinger wrote:
> > > > Again for there, it comes down to the basic design question:
> > > > 
> > > > Will the kernel mode target engine be based on SCSI and live in
> > > > drivers/iscsi, or should the target engine use common code to provide
> > > > infrastructure for SCSI and non SCSI based storage fabrics..?
> > > 
> > > That sounds like a perfect topic for the scsi mailing list, why not take
> > > it there right now and get it resolved this week?
> > > 
> > 
> > Heh, we have been going around and around on the topic for so long on
> > Linux-SCSI, and no one is happy with the current results.  
> > 
> > I am definately willing to throw it out there again, but I am confident
> > that building on the existing design will not take target mode Linux in
> > the direction we want to go, and that making the baby steps to get
> > things moving with the userspace folks in the correct direction to move
> > towards wrt the current situation.
> 
> The problem is that there are two separate constituencies for a target
> mode implementation
> 
>      1. People who need target mode to hack on storage fabrics. For them
>         a user mode implementation is much more easily hackable than a
>         kernel one.

I have no problem with a method to make things easier for developers to
get involved with the code.  What I do have a problem with in where this
requirement outweighs those for real production usage, and where the
production code has to build upon a foundation that makes life difficult
for real production code.

>      2. People who want maximal efficiency in the target.  For them,
>         shoving everything into the kernel seems to be the best thing to
>         do.
> 

Well, there are cases where keeping the fabric is userspace is just not
possible.  Namely the cases of supporting target mode for FC, SAS or
PSCSI target mode hardware.

> The problem is that the currently upstream STGT implementation satisfies
> the first constituency.  The loud clamour for upstreaming SCST is to
> satisfy the second.  Amazingly enough, I think both constituencies have
> a right to a solution.

Having a tool for development and exploration is fine, but I honestly
don't think keeping the requirement for fabrics in userspace makes
sense.  Having a method for userspace passthrough is very important I do
believe however.

>   I also don't think two separate solutions with
> non overlapping code bases in the kernel is the right thing to do,

Definately not.

>  so
> what I'd like is for us to evolve the existing solution into something
> that will work for both (by taking pieces of the out of SCST and placing
> them into STGT).

I really think the problem is more fundemental than that.  I really
don't see how fabrics in userspace benefits any of us looking for real
production infrastructure and code, and espically not when the software
fabrics that we want to port to a generic kernel-level target mode
engine have been stable for years.  

> 
> The problem is that proponents of constituency number 2 term the code
> for constituency 1 "flawed" because they don't see anything in user
> space satisfying their efficiency need.  Until we can get past this
> either 1 or 2 mentality there is going to be no progress because
> "progress" is offered as take it or leave it solutions for either
> constituency.
> 

For me, the Linux-iSCSI.org users, and VHACS storage cloud developers,
we want production code iSCSI target code connected to a generic
kernel-level target mode engine.  Having a mechinism where people can
play (as with #1) is fine, but keeping this requirement for play, when
real work (as with #2) is knocking down the door is a requirement that
does not benefit our production requirements.

> The solution I offered that I think might satisfy both is the ability to
> run pieces of the current STGT in-kernel to get the efficiency gains.  I
> haven't heard any other solutions proposed that would satisfy both ...
> unless I've missed something?
> 

Well, the main thing missing is that all of the discussion has been SCSI
target mode kernel vs. user, and not generic target mode for both SCSI
and now SCSI, with a userspace passthrough for IOs and Data that have
already gone through the kernel level fabric logic, and kernel level
target mode engine..

--nab

> James
> 
> 
>