From: Daniel Phillips <phillips@phunq.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet
Date: Sun, 16 Mar 2008 13:57:03 -0800
User-Agent: KMail/1.9.5
Cc: Willy Tarreau <w@1wt.eu>, David Newall <davidn@davidnewall.com>,
       linux-kernel@vger.kernel.org
References: <200803092346.17556.phillips@phunq.net> <200803151500.05993.phillips@phunq.net> <20080315230558.12e9c96c@the-village.bc.nu>
In-Reply-To: <20080315230558.12e9c96c@the-village.bc.nu>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803161457.04580.phillips@phunq.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1908
Lines: 42

On Saturday 15 March 2008 16:05, Alan Cox wrote:0
> > ,,,interpreting a barrier to mean flush through to rotating media...
> > performance will drop to the millisecond per transaction zone...
> 
> That isn't anything to do with what was being proposed. *ORDERING* not
> flush to media.

This is where you have made a fundamental mistake in your proposal.
Suppose you have a steady, heavy write load onto ramback.  Eventually,
the entire ramdisk will be dirty and you have to drop back to disk
speed, right?  My design does not suffer from that problem, but your
proposal does.

It gets worse than that.  Suppose somebody writes the same region
twice, how do you order that?  Do you try to store that new data
somewhere, keeping in mind that we are already at terabyte scale?  Is
there a limit on how much overwrite data you may have to store?  (No.)

> I want the speed and reliability. Without that ramback is a distraction
> until someone solves the real problems.

Somebody has.  But please feel free to solve some other problem.  I
would love to see a detailed design from you, or a patch.

> > they need to achieve microsecond level transaction throughput and data
> 
> You have no guarantee of commit to stable storage so your use of the word
> "transaction" is a bit farcical.

The UPS provides a guarantee of commit to stable storage.  No amount of
FUD will change that.  But please go ahead and calculate the risks
involved.  I am confident you will admit that there are standard]
techniques available to ameliorate risk, which may be applied _on top of_
ramback, thus not destroying its microsecond-level transaction
performance as you propose.

Daniel
--
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/