Xref: utzoo comp.unix.aix:712 comp.periphs.scsi:144 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.aix,comp.periphs.scsi Subject: Re: Risc System/6000 Message-ID: Date: 12 Mar 90 01:21:15 GMT References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <1990Mar9.022931.4674@world.std.com> <132788@sun.Eng.Sun.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 24 >My own personal opinion is that geometry based filesystems are >getting to be a bad microoptimization. You might want to separate issues of placement and command sorting. If the disk controller is prepared to reorder transactions, and does so well, then I agree it's a mistake for the kernel to do so. It should just get transfer requests to the controller as quickly as possible. The controller is in a better position to know what the heads are doing. However it probably still makes sense for the kernel to try to place blocks of files in positions that require minimal effort to read. I don't know of any controllers that are prepared to take over management of the file system. (In fact even the capability to reorder transactions doesn't seem to be present in most SCSI controllers that are actually available.) It's not clear how much this requires the kernel to know about the disk geometry. My suspicion is that the standard BSD file placement code gains something even if it doesn't know where the exact track boundaries are. At least it will tend to keep files reasonably compact. This assumes that SCSI controllers will map logical to physical addresses in a monotonic fashion, even if it can't be exactly linear. (Apparently some do a better job of this than others. I take this into account when buying disk drives.)