From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751469AbWFJCDc (ORCPT ); Fri, 9 Jun 2006 22:03:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751466AbWFJCDc (ORCPT ); Fri, 9 Jun 2006 22:03:32 -0400 Received: from thunk.org ([69.25.196.29]:62898 "EHLO thunker.thunk.org") by vger.kernel.org with ESMTP id S1751457AbWFJCDb (ORCPT ); Fri, 9 Jun 2006 22:03:31 -0400 Date: Fri, 9 Jun 2006 22:03:06 -0400 From: Theodore Tso To: Jeff Garzik Cc: "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 Subject: Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3 Message-ID: <20060610020306.GA449@thunk.org> Mail-Followup-To: Theodore Tso , Jeff Garzik , "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 References: <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> <448A23B2.5080004@garzik.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448A23B2.5080004@garzik.org> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 09, 2006 at 09:43:14PM -0400, Jeff Garzik wrote: > >??? 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. Nope! Inodes per group and inode blocks per group are maintained across an online resize. So there is no difference in inodes per group for a filesystem created at size S1 and resized to size S2 (using either an on-line or off-line resize), and a filesystem which is created to be size S2. As Andreas has said, "you don't know what you are talking about." - Ted