linux-kernel - Re: Integration of SCST in the mainstream Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.00.0802041130140.3034@hp.linux-foundation.org>
Date:	Mon, 4 Feb 2008 11:44:31 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Vladislav Bolkhovitin <vst@...b.net>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-scsi@...r.kernel.org, scst-devel@...ts.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mike Christie <michaelc@...wisc.edu>
Subject: Re: Integration of SCST in the mainstream Linux kernel

On Mon, 4 Feb 2008, Nicholas A. Bellinger wrote:
> 
> While this does not have anything to do directly with the kernel vs. 
> user discussion for target mode storage engine, the scaling and latency 
> case is easy enough to make if we are talking about scaling TCP for 10 
> Gb/sec storage fabrics.

I would like to point out that while I think there is no question that the 
basic data transfer engine would perform better in kernel space, there 
stll *are* questions whether

 - iSCSI is relevant enough for us to even care ...

 - ... and the complexity is actually worth it.

That said, I also tend to believe that trying to split things up between 
kernel and user space is often more complex than just keeping things in 
one place, because the trade-offs of which part goes where wll inevitably 
be wrong in *some* area, and then you're really screwed.

So from a purely personal standpoint, I'd like to say that I'm not really 
interested in iSCSI (and I don't quite know why I've been cc'd on this 
whole discussion) and think that other approaches are potentially *much* 
better. So for example, I personally suspect that ATA-over-ethernet is way 
better than some crazy SCSI-over-TCP crap, but I'm biased for simple and 
low-level, and against those crazy SCSI people to begin with.

So take any utterances of mine with a big pinch of salt.

Historically, the only split that has worked pretty well is "connection 
initiation/setup in user space, actual data transfers in kernel space". 

Pure user-space solutions work, but tend to eventually be turned into 
kernel-space if they are simple enough and really do have throughput and 
latency considerations (eg nfsd), and aren't quite complex and crazy 
enough to have a large impedance-matching problem even for basic IO stuff 
(eg samba).

And totally pure kernel solutions work only if there are very stable 
standards and no major authentication or connection setup issues (eg local 
disks).

So just going by what has happened in the past, I'd assume that iSCSI 
would eventually turn into "connecting/authentication in user space" with 
"data transfers in kernel space". But only if it really does end up 
mattering enough. We had a totally user-space NFS daemon for a long time, 
and it was perfectly fine until people really started caring.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/