From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [RFC 0/13] extents and 48bit ext3 Date: Fri, 09 Jun 2006 13:48:02 -0400 Message-ID: <4489B452.4050100@garzik.org> References: <1149816055.4066.60.camel@dyn9047017069.beaverton.ibm.com> <20060609091327.GA3679@infradead.org> <20060609030759.48cd17a0.akpm@osdl.org> <44899653.1020007@garzik.org> <20060609095620.22326f9d.akpm@osdl.org> <4489AAD9.80806@garzik.org> <20060609103543.52c00c62.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org, ext2-devel@lists.sourceforge.net, cmm@us.ibm.com, linux-kernel@vger.kernel.org Return-path: To: Andrew Morton In-Reply-To: <20060609103543.52c00c62.akpm@osdl.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ext2-devel-bounces@lists.sourceforge.net Errors-To: ext2-devel-bounces@lists.sourceforge.net List-Id: linux-fsdevel.vger.kernel.org Andrew Morton wrote: > On Fri, 09 Jun 2006 13:07:37 -0400 > Jeff Garzik wrote: > >> I would propose the obvious... 'cp -a ext3 ext4', apply the extent and >> 48bit patches, and then do the obvious search-n-replace. > > Most of ext3 is JBD. At least, in terms of complexity. And I don't think > there's anything in this proposal which affects JBD, apart from changing > the blocksize. > > Cloning JBD for this exercise would, I suspect, be the wrong thing to do - > the two clones would be pretty much identical, apart from some scalar > types. > > I did suggest a couple of years ago that we should clone the ext3 part and > have both ext3 and ext4 use the same JBD layer - I don't know what happened > to that idea. The JBD API is reasonably distinct, so IMO this would be a logical next step. I would hope they could use the same JBD, so, I strongly agree... > There has been steady, cautious but significant improvement happening in > ext3 over the past few years. I'd expect that to continue, although > perhaps at a lower rate. Having to apply the same changes to two > filesystems would be an obvious loss. I disagree completely... it would be an obvious win: people who want stability get that, people who want new features get that too. > It comes down to looking at the patches, and I haven't done that in quite > some time. Ideally the new functionality would all be under CONFIG_foo, > but I do not know if that is being proposed here? > >> We need to draw a line in the sand. If we don't, no one ever will. > > You speak as if this is something which has happened before, or that it will > happen again. > > All that being said, Linux's filesystems are looking increasingly crufty > and we are getting to the time where we would benefit from a greenfield > start-a-new-one. That new one might even be based on reiser4 - has anyone > looked? It's been sitting around for a couple of years. reiser4 actually has this same problem, but worse. It has pluggable metadata even to the point of supporting plugin-style metadata development. If we can successfully devolve a filesystem to metadata and algorithm plugins, that should be done at the VFS level, and not called "reiser4". But in the absence of a different VFS API, I think it is the most practical of all the options to open the floodgates to ext4 rather than ext3. Jeff