From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Tso Subject: Re: [RFC 0/13] extents and 48bit ext3 Date: Fri, 9 Jun 2006 20:47:27 -0400 Message-ID: <20060610004727.GC7749@thunk.org> References: <4489B83E.9090104@sbcglobal.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , Matthew Frost , "Stephen C. Tweedie" , "ext2-devel@lists.sourceforge.net" , linux-kernel , Linus Torvalds , Mingming Cao , linux-fsdevel@vger.kernel.org, Alex Tomas Return-path: To: Jeff Garzik Content-Disposition: inline In-Reply-To: <448A07EC.6000409@garzik.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 On Fri, Jun 09, 2006 at 07:44:44PM -0400, Jeff Garzik wrote: > Yes. Re-read what I wrote. To put it another way, "mkfs S1 + resize to > S2" does not produce precisely the same layout as "mkfs S2". Different in the same way that "mke2fs -E stride=5" results a slightly different location of where the block bitmaps, inode bitmaps, and inode table might be, yes --- but SO WHAT? There's a *reason* that the block group descriptors tell the kernel where to find the block/inode bitmaps and the inode table. They can change due to bad blocks in the filesystem, or requests to subtly change the layout to optimize various RAID layouts, for example. And exactly how the block/inode bitmaps would get laid out in response to -E stride have also changed over time, depending on which version of e2fsprogs, but ---- News flash!! --- it doesn't matter!!! 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!". Oh my, hide the women and children... - Ted