Date: Sun, 16 Mar 2008 23:49:27 -0700 (PDT)
From: david@lang.hm
To: Daniel Phillips <phillips@phunq.net>
cc: David Newall <davidn@davidnewall.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
       Willy Tarreau <w@1wt.eu>, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet
In-Reply-To: <200803162252.58274.phillips@phunq.net>
Message-ID: <alpine.DEB.1.00.0803162341340.14887@asgard.lang.hm>
References: <200803092346.17556.phillips@phunq.net> <200803161942.01944.phillips@phunq.net> <alpine.DEB.1.00.0803162052160.14887@asgard.lang.hm> <200803162252.58274.phillips@phunq.net>
User-Agent: Alpine 1.00 (DEB 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2809
Lines: 68

On Sun, 16 Mar 2008, Daniel Phillips wrote:

> 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.  This strategy has the nice effect of consolidating rewrites.
> There are also excellent delta compression opportunities.
>
> In the worst case, with insufficient bandwidth for the churn rate of
> the volume, replication rate increases to the time for replicating the
> full volume.  Again, at worst, this would require extra storage for the
> snapshot to be replicated equivalent to the original volume size, so
> that the primary volume is not forced to wait synchronously for a
> replication cycle to complete.
>
> Mirroring on the other hand, makes a realtime copy of a volume, that is
> never out of date.

so just mirror to a local disk array then.

a local disk array has more write bandwidth than a network connection to a 
remote machine, so if you can mirror to a remote machine you can mirror to 
a local disk array.

> I hope this helps.

not in the least.

>> on an enterprise level
>> machine the network can frequently be significantly slower than the disk
>> array that you are so frantic to avoid waiting for.
>
> Frantic... your word.  Designing for dependably high transaction rates
> requires a different mode of thinking that some traditionalists seem to
> be having some trouble with.

if by traditionalists you mean everyone who makes a living keeping systems 
running you are right. we want sane failure modes as much as we want 
performance.

there will be times when we decide to go for speed at the expense of 
safety, but we want to do it knowingly, not when someone is promising both 
and only provides speed.

and by the way, if the violin box use your software they have just moved 
from a resource for me to tap when needed to something that I will advise 
my company to avoid at all costs.

David Lang
--
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/