Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755222AbYBDVBt (ORCPT ); Mon, 4 Feb 2008 16:01:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752751AbYBDVBk (ORCPT ); Mon, 4 Feb 2008 16:01:40 -0500 Received: from pie.citi.umich.edu ([141.211.133.115]:42584 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbYBDVBk (ORCPT ); Mon, 4 Feb 2008 16:01:40 -0500 Date: Mon, 4 Feb 2008 16:01:21 -0500 To: Linus Torvalds Cc: "Nicholas A. Bellinger" , James Bottomley , Vladislav Bolkhovitin , Bart Van Assche , Andrew Morton , FUJITA Tomonori , linux-scsi@vger.kernel.org, scst-devel@lists.sourceforge.net, Linux Kernel Mailing List , Mike Christie Subject: Re: Integration of SCST in the mainstream Linux kernel Message-ID: <20080204210121.GF18682@fieldses.org> References: <47A05CBD.5050803@vlnb.net> <47A7049A.9000105@vlnb.net> <1202139015.3096.5.camel@localhost.localdomain> <47A73C86.3060604@vlnb.net> <1202144767.3096.38.camel@localhost.localdomain> <47A7488B.4080000@vlnb.net> <1202145901.3096.49.camel@localhost.localdomain> <1202151989.11265.576.camel@haakon2.linux-iscsi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) From: "J. Bruce Fields" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1577 Lines: 32 On Mon, Feb 04, 2008 at 11:44:31AM -0800, Linus Torvalds wrote: ... > 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). ... > 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. I'd assumed the move was primarily because of the difficulty of getting correct semantics on a shared filesystem--if you're content with NFS-only access to your filesystem, then you can probably do everything in userspace, but once you start worrying about getting stable filehandles, consistent file locking, etc., from a real disk filesystem with local users, then you require much closer cooperation from the kernel. And I seem to recall being told that sort of thing was the motivation more than performance, but I wasn't there (and I haven't seen performance comparisons). --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/