Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!lucy.swin.edu.au!news.rmit.EDU.AU!goanna.cs.rmit.edu.au!news.apana.org.au!cantor.edge.net.au!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!dispatch.news.demon.net!demon!fido.news.demon.net!demon!sun4nl!star.cs.vu.nl!not-for-mail From: kjb=730999@cs.vu.nl (Kees J Bot) Newsgroups: comp.unix.bsd.misc,comp.os.linux.misc Subject: Re: Linux vs BSD Date: Tue, 8 Apr 1997 16:30:33 +0200 Organization: One Minix-vmd system, it works! Message-ID: <9qkdi5.eqe.ln@mega.am.cs.vu.nl> References: <32DFFEAB.7704@usa.net> <E8A0C3.27o.0.staffin.dcs.ed.ac.uk@dcs.ed.ac.uk> <df7di5.voe.ln@mega.am.cs.vu.nl> <5idb0d$4qn@news.ox.ac.uk> NNTP-Posting-Host: mega.am.cs.vu.nl Lines: 51 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.misc:2959 comp.os.linux.misc:168972 In article <5idb0d$4qn@news.ox.ac.uk>, Malcolm Beattie <mbeattie@sable.ox.ac.uk> wrote: >In article <df7di5.voe.ln@mega.am.cs.vu.nl>, >Kees J Bot <kjb=730999@cs.vu.nl> wrote: >>In article <E8A0C3.27o.0.staffin.dcs.ed.ac.uk@dcs.ed.ac.uk>, >>Scott Telford <st@epcc.ed.ac.uk> wrote: >>>In article <5gjsc9$2cm@innocence.interface-business.de>, J Wunsch >>>(j@ida.interface-business.de) wrote: >>> >>>> This might be because Linux doesn't have the concept of a `raw device' >>>> at all. I always wondered why they diminished this idea, and the >>> >>>I suspect it's mainly because Minix didn't have raw devices either. >[...] >>>The legacy of Linux's origins can still be found if you look closely... >> >>Linus may have missed the concept of raw devices because Minix didn't >>make a point of mentioning the idea, neither in /dev/ nor in the code. > >No, Linus has considered and explicitly rejected the idea of adding >raw devices to Linux. From time to time, when provoked, he has posted >about his reasoning. I don't want to put words in his mouth but, as I >recall, it's that one should optimise for the common case and make it >as good as possible. In this case, that means having an excellent >buffer cache, page cache and so on. Adding raw devices as a back-door >because you want a small performance gain in exceptional cases is not >desirable. And if the performance gain for raw devices is not small >then that's a reason to improve the main I/O subsystem rather than >a reason to add support for raw devices. That's true, but for me the prime reason to have raw devices is that I/O is direct, not performance. You can read or write in the device's block size units, not the 1k unit size of the file system, and both read and write errors are reported. This is rather nice if you want to pinpoint bad blocks and such. Not very spectacular, but since we have raw devices for Minix, why not use them. Compared to the scatter/gather code that was later added to the disk drivers, raw device access was a trivial thing to keep going. Not much functionality, and not much work to keep the functionality, so keep it. But note that this may not be true for Linux, so if raw I/O was a major hindrance to make efficient drivers than Linus was right to omit the functionality. (It is nice however to be able to say that an Adaptec 1542B can sustain 2.7Mbyte per second using a fast enough disk. Minix raw I/O overhead is close to nothing, so I can do reliable throughput tests. (It's time I got the NCR53C810 driver going so I can do tests with current hardware. Noone cares about the Adaptec 154x series anymore.)) -- Kees J. Bot, Systems Programmer, Vrije Universiteit Amsterdam