On Sat, 2008-12-13 at 09:24 -0600, James Bottomley wrote: > On Sat, 2008-12-13 at 12:56 +0100, Bart Van Assche wrote: > > On Sat, Dec 13, 2008 at 12:18 PM, Nicholas A. Bellinger > > <nab@xxxxxxxxxxxxxxx> wrote: > > > Of course I fix bugs when people report them. Hi James, > OK, All of you on this thread, why don't you take time out to step back > and think about the effects this descent into trench warfare is having > on your observers. > Yes, I think this reflects very poorly on both of us. I would like to apologize for my part in thread, and would like to start making forward progress again. (eg: more patch bombs :-) > 1. You're both saying the other side isn't production ready ... > it's not a stretch for the rest of us to take this at face > value ... about both of you. So, as some of these larger LIO-Target customers come online in 2009 (including a 500 TB -> 1 PB installation), folks will be able to hear for themselves how Linux-iSCSI.org code is being used for production. Also, there will be full-time engineering resources put on Target_Core_Mod/ConfigFS and LIO_Target v3.0 code in 2009, as we continue to work towards code submission. > 2. This ideological opposition to features the other side > implements tells me that if it came to a choice, by going with > either one of you I'd get an incomplete feature set. Well, I have no ideological opposition to SCST, just technical concerns that never get to be addressed. Which is fine with me, as the pieces I need for LIO-iSER for generic struct page zero-copy mapping using a single codepath to Linux storage subsystem that can be shared across $FABRIC_MODs are already in place for Target_Core_Mod/ConfigFS. Its simply a matter of hooking them (the $FABRIC_MODs) up now. On the other side however, the SCST guys are completely opposed to any usage of ConfigFS, which is a shame because it really does rock for this type of usage: lots of groups, attributes, and $STORAGE_OBJECTS representing Target Ports across multiple $FABRIC_MODs using ConfigFS symlinks. Having written a bunch of ConfigFS code that has been up and running for a few months (most of which was done at LPC), and yet still some people make noise on their precieved limitiations of ConfigFS., without actually ever looking at the code in question. This obviously is a bit of a let down. The good news however is that there are folks in the kernel community who have given me positive feedback about the use of ConfigFS for target mode (and the actual code), and related to me that they believe ConfigFS is the right choice moving forward. (A big thanks to people :-) > 3. Making obvious partisans of your user base also tells me that if > I had to make a choice, whatever it was I'd piss off a large > number of people who'd be very vocal about it. > Honestly, I think our respective userbases just want the best upstream kernel code possible, which is the only thing I am interested in. > Since we have a working target solution in the kernel already (STGT), > why on earth would I be stupid enough to want to even consider either of > you, coming as you do with the above mentioned baggage? > > So stop fighting ... you're not going to backstab your way to inclusion. > Definately not. > The only identified failing of STGT (and it's theoretical, not > demonstrated, although I can agree the theory looks correct) is that the > user space packet processing may cause performance problems on high > speed networks. We know from practical tests that these networks have > to be above 1Gbit because the results were identical for STGT and SCST > on a 1G network, so it's infiniband or 10Gbit ethernet. > As I mentioned during our discussion @ LPC, I am still interested in including support for STGT and userspace fabric modules in Target_Core_Mod/ConfigFS using existing STGT code. So, I am currently at the point where I am bringing LIO-Target v3.0 online using a generic target API on top of Target_Core_Mod/ConfigFS. At this point, I am creating my own 'template' of function pointers that generic target code calls into $FABRIC_MOD. However, I have been considering using an existing 'template', and I am leaning to use the existing the STGT template (moved up to kernel space). I think that using an existing 'template' would help $FABRIC_MODs maintainers port over their code. Same goes for STGT's struct iscsi_transport for the LIO-iSER bits.. > So, what it comes down to is that if we had a kernel side protocol > accelerator for STGT, the project would no longer suffer from this > theoretical failing. *Both* of you have such a thing embedded in your > respective submissions (all 74k LOC of them) so can't you just enhance > STGT with whichever one is better .. Ok, in terms of LOC, I am looking at ~22k LOC for Target_Core_Mod/Configfs (which will be submitted first), and ~18K LOC for LIO-Target v3.0 (submitted later) > . actually, if you'd both bury the > hatchet and work on the enhancement together taking the best of each > project, we'd have something that worked much better and a unified user > base and neither side would be able to claim sole credit ... just a > thought. > I really do apperciate your thoughtful comments, but as long as ConfigFS is being used, I do not believe the SCST folks have any interest in working with me, which is OK. On the bit about claiming sole credit, I very much understand that it 'takes a village' for something as complex as what we are discussing here, and I am very much willing to share credit where credit is due. I am 100% commited for the long haul to the best generic kernel target infrastructure and $FABRIC_MODs, and am very much looking forward to working with people who share this same passion to produce the best possible code. Many thanks for your most valuable of time, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
