Daniel Phillips wrote:
quoted text
> On Sunday 16 March 2008 20:59, david@lang.hm wrote:
>   
>> On Sun, 16 Mar 2008, Daniel Phillips wrote:
>>     
>>> On Sunday 16 March 2008 18:31, David Newall wrote:
>>>       
>>>> Daniel Phillips wrote:
>>>>         
>>>>> The UPS provides a guarantee of commit to stable storage.  No amount of
>>>>> FUD will change that.
>>>>>           
>>>> What about system crashes?  They guarantee that data will be lost.  I
>>>>         
>>> Not if it is mirrored and replicated.  Also nice if crashes are very
>>> rare, which they are unless you work at it.
>>>       
>> if you are depending on replication over the network you have just limited 
>> your throughput to your network speed and latency.
>>     
>
> Replication does not work that way.  On each replication cycle, the
> differences between the most recent two volume snapshots go over the
> network. [...]
> Mirroring on the other hand, makes a realtime copy of a volume, that is
> never out of date.
>   

I think you've just tried to obfuscate the truth.  As you have
described, replication does not provide full protection against data
loss; it loses all changes since last cycle.  Recall that it was you who
introduced the word "replication", in the context of guaranteeing no
loss of data.  Then you ignored David's point about the relatively low
speed of networks, remarking only that mirroring is real-time.  Reading
between your words makes clear that "mirroring and replication" does
reduce the performance.  (You claimed microsecond-level transaction times.)


quoted text
> Designing for dependably high transaction rates
> requires a different mode of thinking that some traditionalists seem to
> be having some trouble with.

You've rather under-valued dependability, though.  Even your idea of
mirroring systems is incomplete, because failure of the principle system
requires transparent fail-over to the redundant system, which is
actually quite challenging, especially with commodity systems hobbled
together in the way you promote.  Remember that you claimed
microsecond-level transaction times, and 6-nines of availability.  The
former seems unlikely with replicated systems and, in the event of a
failure, you won't achieve the latter.

You still haven't investigated the benefit of your idea over a whopping
great buffer cache.  What's the point in all of this if it turns out, as
Alan hinted should be the case, that a big buffer cache gives much the
same performance?  You appear to have gone to a great deal of effort
without having performed quite simple yet obvious experiments.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/