From owner-freebsd-arch Thu Nov 2 14:29: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id A61EB37B479 for ; Thu, 2 Nov 2000 14:29:05 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id XAA97354; Thu, 2 Nov 2000 23:29:03 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id XAA13548; Thu, 2 Nov 2000 23:29:03 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 2 Nov 2000 23:29:03 +0100 (CET) From: Marius Bendiksen To: Alfred Perlstein Cc: Matt Dillon , Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-Reply-To: <20001102132140.W20567@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Block indirection could be optimized by attempting to allocate > indirect blocks in the same area as either the inode or datablocks > that the indirect blocks address. Actually, block indirection could be fixed by raping the code to support the notion of extents. As to allocating in the general locality of the inode or datablock, that would require you to be within a distance of 1 track, and on a system with better things to spend its cache on than indirect blocks, you'll lose some when you hit double or triple indirect, especially with random access. As a side note, I've thought about abusing the actual inodes themselves to hold single indirect blocks. Opinions, apart from the general evilness of abusing the structures in such a fashion? > Yes, patches would be nice. :) Patches cannot be formed until a general consensus exists on how the patches should do things if and when an enterprising soul made them. Otherwise, they stand a good chance at being rejected based on some, possibly relevant, objection to how they work. Also, such patches are likely best formed by the same people that are currently suggesting doing a variety of other things for disklabel and friends. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message