From owner-freebsd-fs@FreeBSD.ORG Sun Nov 13 18:12:16 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE8216A444 for ; Sun, 13 Nov 2005 18:12:16 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 065DD43D46 for ; Sun, 13 Nov 2005 18:12:13 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id jADIC34x005950; Sun, 13 Nov 2005 10:12:03 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200511131812.jADIC34x005950@gate.bitblocks.com> To: Scott Long In-reply-to: Your message of "Sun, 13 Nov 2005 10:17:23 MST." <43777523.8020709@samsco.org> Date: Sun, 13 Nov 2005 10:12:03 -0800 From: Bakul Shah Cc: freebsd-fs@freebsd.org, user , delphij@delphij.net Subject: Re: UFS2 snapshots on large filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2005 18:12:16 -0000 > The idea of doing alternate directory layouts (such as b-trees) has been > proposed a number of times. Apparently there was an idea at one point > for UFS to generate a b-tree layout for directory and and save it on > disk as a cache. The primary method of directory storage would remain > the traditional linear way so that compatibility is preserved, but OS's > that were aware of the cache could use it too. There are still some > reserved flags and fields in UFS2 for doing this, in case you're > interested. Since it requires double bookkeeping for link creation and > removal, I'm not sure how speedy it is for anything other than > VOP_LOOKUP operations. An alternate idea I've had is to break with > compatibility and doing b-trees or something similar as the native > format for UFS3 (along with native journalling and other things). Or *BSD can do something really radical: use the on-disk format of XFS. Why go to a new disk format when an existing one like XFS is good enough. From scratch BSD licensed code can probably be written faster than "evolving" UFS2 to UFS3 when you add in time to fully test and debug either implementation. [But IANAL and don't know if a) this will contravene the DMCA or b) it will be used by FSF to prevent such reverse engineering:-)]