From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750970AbWFKQfp (ORCPT ); Sun, 11 Jun 2006 12:35:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751032AbWFKQfo (ORCPT ); Sun, 11 Jun 2006 12:35:44 -0400 Received: from mail.clusterfs.com ([206.168.112.78]:53447 "EHLO mail.clusterfs.com") by vger.kernel.org with ESMTP id S1750968AbWFKQfn (ORCPT ); Sun, 11 Jun 2006 12:35:43 -0400 From: Nikita Danilov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17548.17729.270931.583125@gargle.gargle.HOWL> Date: Sun, 11 Jun 2006 20:30:57 +0400 To: Arjan van de Ven Cc: Matthew Frost , Alex Tomas , Linus Torvalds , Andrew Morton , ext2-devel , linux-kernel@vger.kernel.org, cmm@us.ibm.com, linux-fsdevel@vger.kernel.org Subject: Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3 Newsgroups: gmane.linux.file-systems,gmane.comp.file-systems.ext2.devel,gmane.linux.kernel In-Reply-To: <1150041738.3131.79.camel@laptopd505.fenrus.org> References: <4488E1A4.20305@garzik.org> <20060609083523.GQ5964@schatzie.adilger.int> <44898EE3.6080903@garzik.org> <448992EB.5070405@garzik.org> <448997FA.50109@garzik.org> <44899A1C.7000207@garzik.org> <4489B83E.9090104@sbcglobal.net> <20060609181426.GC5964@schatzie.adilger.int> <4489C34B.1080806@garzik.org> <1150041738.3131.79.camel@laptopd505.fenrus.org> X-Mailer: VM 7.17 under 21.5 (patch 17) "chayote" (+CVS-20040321) XEmacs Lucid Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Arjan van de Ven writes: > On Fri, 2006-06-09 at 14:51 -0400, Jeff Garzik wrote: > > PRECISELY. So you should stop modifying a filesystem whose design is > > admittedly _not_ modern! > > > > ext3 is already essentially xiafs-on-life-support, when you consider > > today's large storage systems and today's filesystem technology. Just > > look at the ugly hacks needed to support expanding an ext3 filesystem > > online. > > > actually I think I disagree with you. One thing I've noticed over the > years is that ext2 layout has one thing going for it: it is simple and > robust. Maybe "ext2 layout" is the wrong word, "block bitmap and > direct/indirect block based" may be better. It seems that once you go > into tree space (and I would call htree a borderline thing there) you > get both really complex code and fragile behavior all over (mostly in > terms of "when something goes wrong") Huh? Direct/indirect/double-indirect/... _is_ a tree, albeit not balanced one. What makes s5fs/ffs/ufs/ext* so exceptionally robust is fixed position of inode tables, which provides a guaranteed starting point for fsck under almost any circumstances. Nikita.