Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!hacgate!ladcgw!hermes!fmayhar From: fmayhar@hermes.ladc.bull.com (Frank Mayhar) Newsgroups: comp.unix.wizards Subject: Re: Raw disk I/O Message-ID: <1990Feb15.212708.19046@ladc.bull.com> Date: 15 Feb 90 21:27:08 GMT References: Sender: news@ladc.bull.com (Usenet News) Reply-To: fmayhar@hermes.ladc.bull.com Organization: Bull HN Information Systems Inc. Los Angeles Development Center Lines: 31 In article , marc@focsys.uucp (Marc H. Morin) writes: > I am investigating using the raw disk interface to increase performance > of our application. The application is an imaging system, thus the I/O > consists of large data transfers to and from the disk. > > I need to know a little more about the behaviour > of the raw disk driver (in general) for BSD systems. If it helps, I am > particularly interested in SCSI drives on Sony and Mips workstations. > > 1) Does file locking via fcntl() still apply ? > > 2) I understand the disk is viewed as one single flat-file, but does > this also mean that I must handle bad sectors within my application ? > > 3) Any experiences that you might have had with raw disk I/O. We were looking into this as well. After testing, we decided to continue to use the block device, since it was at least three times faster than the raw device. I concluded then that the block device was doing some disk access optimizations that the raw device wasn't doing. Also, using the block device has the added advantage that any new optimizations in the driver would automatically be used by the application. Of course, we're using System V. I think you'll probably see the same thing under BSD, though. -- Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar) Bull HN Information Systems Inc. Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241