Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!hammer.uoregon.edu!news-xfer.netaxs.com!news.maxwell.syr.edu!news.apfel.de!news-fra1.dfn.de!news-koe1.dfn.de!main.Germany.EU.net!Dortmund.Germany.EU.net!interface-business.de!usenet From: j@ida.interface-business.de (J Wunsch) Newsgroups: comp.unix.bsd.misc,comp.os.linux.misc Subject: Re: Linux vs BSD Date: 17 Mar 1997 16:43:53 GMT Organization: interface business GmbH, Dresden Lines: 43 Message-ID: <5gjsc9$2cm@innocence.interface-business.de> References: <32DFFEAB.7704@usa.net> <slrn5fejrn.353.bet@onyx.interactive.net> <5d7spf$8n6@web.nmti.com> <5d9p55$t1h@news.ox.ac.uk> <5dadfr$cnu@web.nmti.com> <n4stf5.tq2.ln@zen> <E6sIEF.1qE@truffula.sj.ca.us> <prlfg5.bs.ln@zen> <Pine.NEB.3.95.970316102739.709D-100000@sphynx.fdn.fr> Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) NNTP-Posting-Host: ida.interface-business.de X-Newsreader: knews 0.9.6 X-Phone: +49-351-31809-14 X-Fax: +49-351-3361187 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Xref: euryale.cc.adfa.oz.au comp.unix.bsd.misc:2826 comp.os.linux.misc:164888 Philippe CAUSSE <caussep@sphynx.fdn.fr> wrote: > > : Does FreeBSD have a similar weakness? > > It doesn't seem to suffer from this problem... > I'm still running FreeBSD-2.1.6 and performing raw device I/O does not > lock the system at all. > The buffer cache management policy is basically different in BSD-ish > systems... 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 problem described looks like what you get from blasting an entire disk's contents through the buffer cache. To the contrary, for systems that do have raw device, you use them to access an entire disk, and this access doesn't touch the buffer cache at all. That's why it is important to not forget the letter `r' in front of the disk name... There are two other reasons for using raw devices: their access is synchronous, thus you get immediate error reporting. With buffered (block) devices, write operations are asynchronous, thus if a late write error happens, the application has already been reported a `good' status, and the only remaining option for the kernel is to syslog the error. The last thing is that async writes do not have a guaranteed time of completion. The only guarantee is to umount a filesystem that has been mounted over them (which by definition must wait until all outstanding buffers are complete). But if you've been using e.g. /dev/fd0 to write your tar archive to it, when do you know all writes have completed? sync(2) by definition only initiates the writeback, but doesn't wait. I have seen systems (Data General DG/UX 5.something) that never wrote back some 5 KB written to a floppy block device until the system had been shut down. I figure that this isn't the case with Linux, but still the question remains that you never know when exactly the data arrived on the floppy. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j