Date: Mon, 6 Nov 2000 12:21:55 +0100 (CET) From: Marius Bendiksen <mbendiks@eunet.no> To: Randell Jesup <rjesup@wgate.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Matt Dillon <dillon@earth.backplane.com>, arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep Message-ID: <Pine.BSF.4.05.10011061218590.36412-100000@login-1.eunet.no> In-Reply-To: <ybulmv1802x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1 track? Not really. Modern drives have internal caches and > generally aggressively read-ahead. There was an interesting paper in Actually, it is of some relevance, to avoid having to wait for the head to reposition to the next track. Of course, the improvement isn't all that large. > 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? ;-) I was referring to a physical track. Which complicates the matter even further, as we have no idea how logical layout maps to physical layout. > >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. I'll see if I can find the time to run some tests on this. My scratchbox is finally (after months of waiting) arriving now. > 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. Then you should probably grope for a consensus on aims =) 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.10011061218590.36412-100000>