Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!ut-sally!utah-cs!utah-gr!stride!stride1!mitch From: mitch@stride1.UUCP Newsgroups: comp.arch Subject: Re: Software Page Table Machines Message-ID: <668@stride.Stride.COM> Date: Fri, 15-May-87 14:40:15 EDT Article-I.D.: stride.668 Posted: Fri May 15 14:40:15 1987 Date-Received: Sat, 16-May-87 21:31:34 EDT References: <1968@husc6.UUCP> Sender: news@stride.Stride.COM Reply-To: mitch@stride1.Stride.COM (Thomas P. Mitchell) Organization: MicroSage Comp. Sys. Inc., 680 S. Rock Blvd, Reno, NV 89502 Lines: 28 Summary: is realy disk optimizing In article <1968@husc6.UUCP> reiter@endor.UUCP (Ehud Reiter) writes: >Some friends of mine are playing around with memory-mapped databases. > The above line started me wondering if any system has considerations for per process disk optimizations. For example in a database the person building the code might know the best way to do buffering or read ahead. I know many programs are built to take advantage of known disk optimizations, but not the other way around. Perhaps something like: -=-=--= #include -stuff- int fd; -stuff- fd = open(argv[1], O_RDWR) disk-optim(fd, {BUFFER, READ_AHEAD, READ_BEHIND}) -stuff- Thanks for the Soap Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.