Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757682AbYBDXqS (ORCPT ); Mon, 4 Feb 2008 18:46:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754142AbYBDXqE (ORCPT ); Mon, 4 Feb 2008 18:46:04 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:36230 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753587AbYBDXqB (ORCPT ); Mon, 4 Feb 2008 18:46:01 -0500 Date: Mon, 4 Feb 2008 15:45:19 -0800 (PST) From: Linus Torvalds To: Jeff Garzik cc: "J. Bruce Fields" , "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 In-Reply-To: <47A7986B.1070206@garzik.org> Message-ID: 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> <47A7986B.1070206@garzik.org> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2084 Lines: 45 On Mon, 4 Feb 2008, Jeff Garzik wrote: > > Well, speaking as a complete nutter who just finished the bare bones of an > NFSv4 userland server[1]... it depends on your approach. You definitely are a complete nutter ;) > If the userland server is the _only_ one accessing the data[2] -- i.e. the > database server model where ls(1) shows a couple multi-gigabyte files or a raw > partition -- then it's easy to get all the semantics right, including file > handles. You're not racing with local kernel fileserving. It's not really simple in general even then. The problems come with file handles, and two big issues in particular: - handling a reboot (of the server) without impacting the client really does need a "look up by file handle" operation (which you can do by logging the pathname to filehandle translation, but it certainly gets problematic). - non-Unix-like filesystems don't necessarily have a stable "st_ino" field (ie it may change over a rename or have no meaning what-so-ever, things like that), and that makes trying to generate a filehandle really interesting for them. I do agree that it's possible - we obviously _did_ have a user-level NFSD for a long while, after all - but it's quite painful if you want to handle things well. Only allowing access through the NFSD certainly helps a lot, but still doesn't make it quite as trivial as you claim ;) Of course, I think you can make NFSv4 to use volatile filehandles instead of the traditional long-lived ones, and that really should avoid almost all of the problems with doing a NFSv4 server in user space. However, I'd expect there to be clients that don't do the whole volatile thing, or support the file handle becoming stale only at certain well-defined points (ie after renames, not at random reboot times). Linus -- 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/