Path: utzoo!attcan!uunet!cs.utexas.edu!usc!snorkelwacker!apple!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: mirrored file systems
Message-ID: <131782@sun.Eng.Sun.COM>
Date: 14 Feb 90 00:16:19 GMT
References: <11071@encore.Encore.COM> <4812@amelia.nas.nasa.gov> <11083@encore.Encore.COM> <605@bbxsda.UUCP> <4849@amelia.nas.nasa.gov> <17902@rpp386.cactus.org> <4882@amelia.nas.nasa.gov> <47@xyzzy.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 24

In article <47@xyzzy.UUCP> goudreau@larrybud.dg.com (Bob Goudreau) writes:
>In article <4882@amelia.nas.nasa.gov> truesdel@sun217..nas.nasa.gov (David A. Truesdell) writes:
>>In addition, a mirrored filesystem won't help your I/O throughput.
>
>Actually, that depends on the system's read/write ratio.  Writes to
>a mirrored file system obviously must result in I/O to each (valid)
>side of the mirror.  But reads, on the other hand, only need to
>find *one* good copy.  An intelligently implemented mirrored file
>system can increase I/O throughput by distributing read requests
>evenly among the copies, thus leaving the unused sides of the
>mirror free to service other incoming read requests.

Good point.  Here's something else to consider though, when thinking about
this sort of thing.  When you speak of the  read/write ratio, be careful
to tell me which side of the buffer cache you mean.  The read/write
ratio on the system call side is about 4:1, but on the other side I've
found it's much more like 1:4. In other words, the cache caches lots of
reads, but the writes end up going through (most of the write traffic
I've seen are directory updates since they are synchronous).  Just a 
thought...
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com