From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nikita Danilov <nikita@clusterfs.com>
Subject: Re: [RFC 0/13] extents and 48bit ext3
Date: Sun, 11 Jun 2006 20:30:57 +0400
Message-ID: <17548.17729.270931.583125@gargle.gargle.HOWL>
References: <4488E1A4.20305@garzik.org>
	<20060609083523.GQ5964@schatzie.adilger.int>
	<44898EE3.6080903@garzik.org> <448992EB.5070405@garzik.org>
	<Pine.LNX.4.64.0606090836160.5498@g5.osdl.org>
	<448997FA.50109@garzik.org> <m3irnacohp.fsf@bzzz.home.net>
	<44899A1C.7000207@garzik.org> <m3ac8mcnye.fsf@bzzz.home.net>
	<4489B83E.9090104@sbcglobal.net>
	<20060609181426.GC5964@schatzie.adilger.int>
	<4489C34B.1080806@garzik.org>
	<1150041738.3131.79.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Andrew Morton <akpm@osdl.org>,
	Matthew Frost <artusemrys@sbcglobal.net>,
	ext2-devel <ext2-devel@lists.sourceforge.net>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	cmm@us.ibm.com, linux-fsdevel@vger.kernel.org,
	Alex Tomas <alex@clusterfs.com>
Return-path: <ext2-devel-bounces@lists.sourceforge.net>
To: Arjan van de Ven <arjan@infradead.org>
In-Reply-To: <1150041738.3131.79.camel@laptopd505.fenrus.org>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ext2-devel>,
	<mailto:ext2-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ext2-devel>
List-Post: <mailto:ext2-devel@lists.sourceforge.net>
List-Help: <mailto:ext2-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ext2-devel>,
	<mailto:ext2-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: ext2-devel-bounces@lists.sourceforge.net
Errors-To: ext2-devel-bounces@lists.sourceforge.net
List-Id: linux-fsdevel.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.