From owner-freebsd-hackers Fri Jun 6 14:57:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14861 for hackers-outgoing; Fri, 6 Jun 1997 14:57:53 -0700 (PDT) Received: from riverside.mr.net (root@Riverside.MR.Net [137.192.2.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14854 for ; Fri, 6 Jun 1997 14:57:44 -0700 (PDT) Received: from data.mr.net (root@data.MR.Net [137.192.192.27]) by riverside.mr.net (8.8.5/) with ESMTP id QAA27254 for ; Fri, 6 Jun 1997 16:57:33 -0500 (CDT) Received: from data (fritchie@data.MR.Net [137.192.192.27]) by data.mr.net (8.8.5/8.7.2) with ESMTP id QAA09644 for ; Fri, 6 Jun 1997 16:57:31 -0500 (CDT) Message-Id: <199706062157.QAA09644@data.mr.net> To: freebsd-hackers@freebsd.org Subject: One reason to mmap() block devices Date: Fri, 06 Jun 1997 16:57:30 -0500 From: Scott Lystig Fritchie Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To follow-up to my earlier question about why only regular and character files are mmap()able... ... I'm interested in mmap()ing a disk block device. I've been doing some alternative INN development, bypassing the traditional filesystem for article storage, using instead a few very large files as cyclic buffers. Currently under FreeBSD, these 2GB files are on top of a UFS filesystem. Under Solaris I use the disk partitions' block devices directly to bypass the filesystem overhead. I hadn't tried, until very recently, to use block devices under FreeBSD, and that's when I made my surprise discovery. I'm quite interested, actually, in having the OS interfere with its buffer cache. Under Solaris, INN article acceptance rates using disk character devices is only handful per second, and the drive sounds like automatic rifle fire. With disk block devices, throughput can reach over 200 articles/second, and the drive busy light blinks every now and then. I do have a non-critical machine I could test out a simple mod to allow VREG, VCHR, or VBLK type files ... but I figured I'd ask, just in case there might be something which I wouldn't notice if the machine weren't heavily stressed, for example while doing my testing. :-) -Scott --- Scott Lystig Fritchie, Network Engineer MRNet Internet Services, Inc. fritchie@mr.net, PGP key #152B8725 Minnesota Regional Network v: 612/362.5820, p: 612/637.9547 2829 University Ave SE http://www.mr.net/~fritchie/ Minneapolis, MN 55414