Date: Thu, 2 Nov 2000 23:29:03 +0100 (CET) From: Marius Bendiksen <mbendiks@eunet.no> To: Alfred Perlstein <bright@wintelcom.net> Cc: Matt Dillon <dillon@earth.backplane.com>, Randell Jesup <rjesup@wgate.com>, arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep Message-ID: <Pine.BSF.4.05.10011022322581.13327-100000@login-1.eunet.no> In-Reply-To: <20001102132140.W20567@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10011022322581.13327-100000>