Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news-xfer.netaxs.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!rill.news.pipex.net!pipex!blackbush.xlink.net!ka.sub.net!rz.uni-karlsruhe.de!not-for-mail From: uk1o@rzstud2.rz.uni-karlsruhe.de (Felix Schroeter) Newsgroups: comp.unix.bsd.misc,comp.os.linux.misc Subject: Re: Linux vs BSD Date: 18 Mar 1997 18:43:31 +0100 Organization: University of Karlsruhe, Germany Lines: 43 Message-ID: <5gmk83$c9j@rzstud2.rz.uni-karlsruhe.de> References: <32DFFEAB.7704@usa.net> <prlfg5.bs.ln@zen> <Pine.NEB.3.95.970316102739.709D-100000@sphynx.fdn.fr> <5gjsc9$2cm@innocence.interface-business.de> NNTP-Posting-Host: rzstud2.rz.uni-karlsruhe.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: euryale.cc.adfa.oz.au comp.unix.bsd.misc:2855 comp.os.linux.misc:165446 Hello! In article <5gjsc9$2cm@innocence.interface-business.de>, J Wunsch <joerg_wunsch@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 >problem described looks like what you get from blasting an entire >disk's contents through the buffer cache. I think, that *is* a problem. >[...] >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. That is one, too. >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. Under Linux, the close of a block device (e.g. /dev/fd0) blocks until all data has been written. Another approach (which should work *everywhere*) is to write the data, then fsync() the fd, the close it. fsync() is specified to block until the data and all metadata are written to disk. (Perhaps it can even report errors!) Regards, Felix.