Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbYBETBj (ORCPT ); Tue, 5 Feb 2008 14:01:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752077AbYBETBZ (ORCPT ); Tue, 5 Feb 2008 14:01:25 -0500 Received: from mail-relay-02.mailcluster.net ([77.221.130.214]:56403 "EHLO mail-relay-02.mailcluster.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbYBETBY (ORCPT ); Tue, 5 Feb 2008 14:01:24 -0500 Message-ID: <47A8B281.5030701@vlnb.net> Date: Tue, 05 Feb 2008 22:01:21 +0300 From: Vladislav Bolkhovitin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-us, ru, en MIME-Version: 1.0 To: Linus Torvalds CC: "J. Bruce Fields" , Mike Christie , linux-scsi@vger.kernel.org, Linux Kernel Mailing List , "Nicholas A. Bellinger" , James Bottomley , scst-devel@lists.sourceforge.net, Andrew Morton , FUJITA Tomonori Subject: Re: Integration of SCST in the mainstream Linux kernel 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> <20080204210121.GF18682@fieldses.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2012 Lines: 42 Linus Torvalds wrote: >>I'd assumed the move was primarily because of the difficulty of getting >>correct semantics on a shared filesystem > > > .. not even shared. It was hard to get correct semantics full stop. > > Which is a traditional problem. The thing is, the kernel always has some > internal state, and it's hard to expose all the semantics that the kernel > knows about to user space. > > So no, performance is not the only reason to move to kernel space. It can > easily be things like needing direct access to internal data queues (for a > iSCSI target, this could be things like barriers or just tagged commands - > yes, you can probably emulate things like that without access to the > actual IO queues, but are you sure the semantics will be entirely right? > > The kernel/userland boundary is not just a performance boundary, it's an > abstraction boundary too, and these kinds of protocols tend to break > abstractions. NFS broke it by having "file handles" (which is not > something that really exists in user space, and is almost impossible to > emulate correctly), and I bet the same thing happens when emulating a SCSI > target in user space. Yes, there is something like that for SCSI target as well. It's a "local initiator" or "local nexus", see http://thread.gmane.org/gmane.linux.scsi/31288 and http://news.gmane.org/find-root.php?message_id=%3c463F36AC.3010207%40vlnb.net%3e for more info about that. In fact, existence of local nexus is one more point why SCST is better, than STGT, because for STGT it's pretty hard to support it (all locally generated commands would have to be passed through its daemon, which would be a total disaster for performance), while for SCST it can be done relatively simply. Vlad -- 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/