From owner-freebsd-arch Fri Nov 3 8:54: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 175C837B4C5 for ; Fri, 3 Nov 2000 08:54:02 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VT2YCG76; Fri, 3 Nov 2000 11:54:08 -0500 Reply-To: Randell Jesup To: Marius Bendiksen Cc: Alfred Perlstein , Matt Dillon , Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep References: From: Randell Jesup Date: 03 Nov 2000 11:57:58 -0500 In-Reply-To: Marius Bendiksen's message of "Thu, 2 Nov 2000 23:29:03 +0100 (CET)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marius Bendiksen writes: >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. 1 track? Not really. Modern drives have internal caches and generally aggressively read-ahead. There was an interesting paper in SIGOS (I think) around a year ago about inode locality, forward placement, and storing small files in the inode, and how all of this interacted with modern drives. Also, what is a "track" on a modern drive? ;-) >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? That sounds good. >> 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. I'm willing to help on this, though my time may be limited. I have _extensive_ FS experience from my Amiga days, and also was the primary disk-driver person and SCSI expert, and also did "archive" filesystems for Scala. I've never hacked the internals of ufs, however, but I do know the issues. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message