From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [Joel.Becker@oracle.com: Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs] Date: Thu, 25 Aug 2005 11:58:19 +0200 Message-ID: <20050825095819.GA4785@lst.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , mark.fasheh@oracle.com, linux-fsdevel@vger.kernel.org Return-path: Received: from verein.lst.de ([213.95.11.210]:64958 "EHLO mail.lst.de") by vger.kernel.org with ESMTP id S964912AbVHYJ6e (ORCPT ); Thu, 25 Aug 2005 05:58:34 -0400 To: Joel Becker Content-Disposition: inline In-Reply-To: <20050824203352.GB30246@insight.us.oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Aug 24, 2005 at 01:33:52PM -0700, Joel Becker wrote: > On Wed, Aug 24, 2005 at 09:18:35AM +0200, Christoph Hellwig wrote: > > - oracore workarounds must go away > > These are not part of the linus-ward submission. Ok. > > - magic symlinks that pollute the posix filename namespace must go > > away > > We're still trying to come up with a way to solve the problem > without magic symlinks. Suggestions still welcome. That's fine, you're free to come up whatever problem you have of course ;-) Doesn't mean we're gonna put the broken variant into mainline, though. > > - vma-walking locking must move to common code (zab is working on that > > afaik) > > 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. > > - the buffered aio mess needs sorting out. imho the best thing was > > Well, that's a mainline problem. Yes, we should all work > towards improving mainline. But again I'm not sure others are served > keeping OCFS2 out over this. Currently we don't support buffered aio on any filesystem in mainline, so adding crufty code to mainline sounds like a bad idea. Zab agreed on that and wants to remove it as much as it gets. > > - there's still some procfs abuse > > Specifics of what is abuse vs OK would be interesting. You're using procfs for non-process data. > > That's just the off my head things, the oracle people actually asked > > me to wait with a review until they've cleared their TODO lists, I'll > > do a real review once I'll get some time. > > There are some sizeable things on this "top of the head" list > already. I'd like to find a nice balance between "goes to mainline now" > and "must be a perfect piece of software before it goes in." No > software will ever be perfect. That's really the big things, it's certainly not perfect after that.. Note that it's often easier to drop unfished/messy/controversial features and do them right later. That avoids the everything must be perfect syndrome while keeping out the big mess.