Date: Sun, 13 Nov 2005 10:12:03 -0800 From: Bakul Shah <bakul@BitBlocks.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-fs@freebsd.org, user <user@dhp.com>, delphij@delphij.net Subject: Re: UFS2 snapshots on large filesystems Message-ID: <200511131812.jADIC34x005950@gate.bitblocks.com> In-Reply-To: Your message of "Sun, 13 Nov 2005 10:17:23 MST." <43777523.8020709@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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:-)]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511131812.jADIC34x005950>