*BSD News Article 91246


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