Message-Id: <200803131232.07879.phillips@phunq.net>
Date:	Thu, 13 Mar 2008 11:32:06 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	david@...g.hm
Cc:	David Newall <davidn@...idnewall.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On Thursday 13 March 2008 09:25, david@...g.hm wrote:
> On Thu, 13 Mar 2008, Daniel Phillips wrote:
> > My proposition is, you can go out and purchase hardware right now that
> > delivers 6 nines (30 seconds downtime/year) and yes, it will cost you,
> > but if that worries you then set up two (much) cheaper ones and set
> > them up as a failover cluster.  (Helps that the Violin box can connect
> > via PCI-e to two servers at the same time.)
> 
> you just use a redundant system and you no longer care how long it takes 
> to shutdown or startup a system. if you're running a datacenter that cares 
> about uptime to the point of counting 9's or buying a Violin box you are 
> already going to need redundant machines so that you can perform upgrades.

The period where you cannot access the data is downtime.  If your script
just does a cp from a disk array to the ram device you cannot just read
from the backing store in that period because you will need to fail over
to the ramdisk at some point, and you cannot just read from the ramdisk
because it is not populated yet.  My point is, you cannot implement
ramback as a two line script and expect to achieve anything resembling
continuous data availability.

I interpret your point about the script as, Ramback is trivial and easy
to implement.  That is kind of true and kind of untrue, because of the
additional requirements mentioned in my original post.

> > I say you can do this reliably.  It boils down to your power supplies.
> > You say it can't be done.  Who is right?
> 
> it also takes the faith that you will never have any unplanned shutdowns, 

Never is not the right word, but indeed that is why I wrote the story
about the rocket ship.  If you want the performance that ramback
delivers then you cover the risk of hardware failure by other,
standard means.

> since your system will loose massive amounts of data if they happen. 

Why would you assume the data is not mirrored or replicated with a
short cycle, or no other suitable fallback plan is in place?

> nobody who worries about 9's will buy into that argument. you achieve 9's 
> by figuring that things don't always work, and as a result you figure out 
> how to engineer around the failures so that when they happen you stay up. 
> manufacturers have been trying to promise that their boxes are so reliable 
> that they won't go down for decades, and they haven't suceeded yet.

All true.  Now what about the punchcard versus magnetic media story?
There was a time when magnetic domains were considered less reliable
than holes in paper cards, ironically we now think the opposite.  So
some people will have a hard time with the idea that a battery is
reliable enough to get your important cached data on to hard disk when
necessary, or that Linux is reliable enough to trust data to it, or
whatever.  They will get over it.  Battery backed data will become a
normal part of your life as progress marches on.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists