From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3 Date: Fri, 09 Jun 2006 21:43:14 -0400 Message-ID: <448A23B2.5080004@garzik.org> References: <20060609181426.GC5964@schatzie.adilger.int> <4489C34B.1080806@garzik.org> <20060609194959.GC10524@thunk.org> <4489D44A.1080700@garzik.org> <1149886670.5776.111.camel@sisko.sctweedie.blueyonder.co.uk> <4489ECDD.9060307@garzik.org> <1149890138.5776.114.camel@sisko.sctweedie.blueyonder.co.uk> <448A07EC.6000409@garzik.org> <20060610004727.GC7749@thunk.org> <448A1BBA.1030103@garzik.org> <20060610013048.GS5964@schatzie.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:10669 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1751352AbWFJBnZ (ORCPT ); Fri, 9 Jun 2006 21:43:25 -0400 To: Jeff Garzik , Theodore Tso , "Stephen C. Tweedie" , Andrew Morton , Matthew Frost , "ext2-devel@lists.sourceforge.net" , linux-kernel , Linus Torvalds , Mingming Cao , linux-fsdevel@vger.kernel.org, Alex Tomas In-Reply-To: <20060610013048.GS5964@schatzie.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Andreas Dilger wrote: > On Jun 09, 2006 21:09 -0400, Jeff Garzik wrote: >> Theodore Tso wrote: >>> Jeff, you seem to think that the fact that the layout isn't precisely >>> the same after an on-line resizing is proof of something horrible, but >>> it isn't. The exact location of filesystem metadata has never been >>> fixed, not in the past ten years of ext2/3 history, and this is not a >>> big deal. It certainly isn't "proof" of on-line resizing being >>> something horrible, as you keep trying to claim, without any arguments >>> other than, "The layout is different!". >> No, I was proving merely that it is _different_. And the values where >> you see a _difference_ are the ones of which are no longer sized >> optimally, after you grow the fs to a larger size. > > It sounds like you don't know what you are talking about, which is OK, > except that you keep harping on some non-existent point. > >> So you incur a performance penalty for resizing to size S2, rather than >> mke2fs'ing the new blkdev at size S2. Certainly within the confines of >> ext3 that cannot be helped, but a different inode allocation strategy >> could improve upon that. > > ??? Can you please be specific in what the performance penalty is, and > what specifically is "not sized optimally" after a resize? How exactly > does inode allocation strategy relate to anything at all to online resizing. Inodes per group / inode blocks per group, as I've already stated. Jeff