Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757145AbYBERu2 (ORCPT ); Tue, 5 Feb 2008 12:50:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753751AbYBERuO (ORCPT ); Tue, 5 Feb 2008 12:50:14 -0500 Received: from srv5.dvmed.net ([207.36.208.214]:39468 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753695AbYBERuM (ORCPT ); Tue, 5 Feb 2008 12:50:12 -0500 Message-ID: <47A8A1C8.2010407@garzik.org> Date: Tue, 05 Feb 2008 12:50:00 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Bart Van Assche CC: Linus Torvalds , "J. Bruce Fields" , "Nicholas A. Bellinger" , James Bottomley , Vladislav Bolkhovitin , 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 References: <47A05CBD.5050803@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> <47A7986B.1070206@garzik.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Report: SpamAssassin version 3.2.3 on srv5.dvmed.net summary: Content analysis details: (-4.4 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2506 Lines: 60 Bart Van Assche wrote: > On Feb 4, 2008 11:57 PM, Jeff Garzik wrote: > >> Networked block devices are attractive because the concepts and >> implementation are more simple than networked filesystems... but usually >> you want to run some sort of filesystem on top. At that point you might >> as well run NFS or [gfs|ocfs|flavor-of-the-week], and ditch your >> networked block device (and associated complexity). > > Running a filesystem on top of iSCSI results in better performance > than NFS, especially if the NFS client conforms to the NFS standard > (=synchronous writes). > By searching the web search for the keywords NFS, iSCSI and > performance I found the following (6 years old) document: > http://www.technomagesinc.com/papers/ip_paper.html. A quote from the > conclusion: > Our results, generated by running some of industry standard benchmarks, > show that iSCSI significantly outperforms NFS for situations when > performing streaming, database like accesses and small file transactions. async performs better than sync... this is news? Furthermore, NFSv4 has not only async capability but delegation too (and RDMA if you like such things), so the comparison is not relevant to modern times. But a networked filesystem (note I'm using that term, not "NFS", from here on) is simply far more useful to the average user. A networked block device is a building block -- and a useful one. A networked filesystem is an immediately usable solution. For remotely accessing data, iSCSI+fs is quite simply more overhead than a networked fs. With iSCSI you are doing local VFS -> local blkdev -> network whereas a networked filesystem is local VFS -> network iSCSI+fs also adds new manageability issues, because unless the filesystem is single-computer (such as diskless iSCSI root fs), you still need to go across the network _once again_ to handle filesystem locking and coordination issues. There is no _fundamental_ reason why remote shared storage via iSCSI OSD is any faster than a networked filesystem. SCSI-over-IP has its uses. Absolutely. It needed to be standardized. But let's not pretend iSCSI is anything more than what it is. Its a bloated cat5 cabling standard :) Jeff -- 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/