From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263100AbVGAHPx (ORCPT ); Fri, 1 Jul 2005 03:15:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263194AbVGAHPx (ORCPT ); Fri, 1 Jul 2005 03:15:53 -0400 Received: from smtp.osdl.org ([65.172.181.4]:2226 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S263100AbVGAHPe (ORCPT ); Fri, 1 Jul 2005 03:15:34 -0400 Date: Fri, 1 Jul 2005 00:14:39 -0700 From: Andrew Morton To: Miklos Szeredi Cc: aia21@cam.ac.uk, arjan@infradead.org, linux-kernel@vger.kernel.org, frankvm@frankvm.com Subject: Re: FUSE merging? Message-Id: <20050701001439.63987939.akpm@osdl.org> In-Reply-To: References: <20050630022752.079155ef.akpm@osdl.org> <1120125606.3181.32.camel@laptopd505.fenrus.org> <1120126804.3181.34.camel@laptopd505.fenrus.org> <1120129996.5434.1.camel@imp.csi.cam.ac.uk> <20050630124622.7c041c0b.akpm@osdl.org> <20050630235059.0b7be3de.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: > > > > > > > > - aren't we going to remove the nfs semi-server feature? > > > > > > I leave the decision to you ;) It's a separate independent patch > > > already (fuse-nfs-export.patch). > > > > Let's leave it out - that'll stimulate some activity in the > > userspace-nfs-server-for-FUSE area. > > > > Speaking of which, dumb question: what does FUSE offer over simply using > > NFS protocol to talk to the userspace filesystem driver? > > Oh lots: > > - no deadlocks (NFS mounted from localhost is riddled with them) It is? We had some low-memory problems a while back, but they got fixed. During that work I did some nfs-to-localhost testing and things seemed OK. > - efficient protocol, optimized for less context switches One wouldn't really expect a userspace filesystem to be particularly fast, and the performance will be dominated by memory copies and IO wait anyway. > - dcache invalidation policy What's that? > - probably more, but I can't remember Please do..