From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Fasheh Subject: Re: [Joel.Becker@oracle.com: Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs] Date: Thu, 25 Aug 2005 10:45:42 -0700 Message-ID: <20050825174541.GA21228@ca-server1.us.oracle.com> References: <20050822213220.GH19387@insight.us.oracle.com> <20050822144521.24494329.akpm@osdl.org> <20050822215049.GI19387@insight.us.oracle.com> <20050822150505.7978136d.akpm@osdl.org> <20050824071835.GA10235@lst.de> <20050824203352.GB30246@insight.us.oracle.com> <20050825095819.GA4785@lst.de> Reply-To: Mark Fasheh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joel Becker , Andrew Morton , linux-fsdevel@vger.kernel.org, Wim Coekaerts Return-path: Received: from rgminet03.oracle.com ([148.87.122.32]:20643 "EHLO rgminet03.oracle.com") by vger.kernel.org with ESMTP id S1750739AbVHYRqK (ORCPT ); Thu, 25 Aug 2005 13:46:10 -0400 To: Christoph Hellwig Content-Disposition: inline In-Reply-To: <20050825095819.GA4785@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Aug 25, 2005 at 11:58:19AM +0200, Christoph Hellwig wrote: > > The vma-walking will go away, replaced by another mmap scheme > > entirely. However, that's three or four months away. The current code > > is merely a stopgap for now. > > Many folks have an interest in having a cluster filesystem in > > mainline. This seems like an issue that can be resolved later, not a > > big blocker. That is, it would be worth more to people to have it in > > mainline for the next four months, knowing this will get fixed, than > > keeping it out of mainline for four months over this feature. > > I don't think it'll take four month, but we're having a bad predence > here - GFS pretty much duplicates the same mess and if we let that > in we're growing more and more of it. Please get it right conceptually > first, it doesn't have to be perfect. We're fixing this by taking a completely different approach from what is done today, which won't involve vma walking. It *will* take some time however, at least in testing and validation. In the meantime I'd rather not see us do all the work to port something to the VFS which we won't even be using in a few months time. > > > - there's still some procfs abuse > > > > Specifics of what is abuse vs OK would be interesting. > > You're using procfs for non-process data. I'm not sure I understand this... Looking through /proc I see lots of subsystems using /proc in similar ways to us. or is there a very specific method which you have a problem with? --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com