Message-ID: <alpine.DEB.1.00.0803130914320.22040@asgard.lang.hm>
Date:	Thu, 13 Mar 2008 09:25:09 -0700 (PDT)
From:	david@...g.hm
To:	Daniel Phillips <phillips@...nq.net>
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 Thu, 13 Mar 2008, Daniel Phillips wrote:

> On Thursday 13 March 2008 01:39, david@...g.hm wrote:
>>> Feel free.  You use your script, and somebody with a reliable UPS or
>>> two can use my driver, once it is stabilized of course.  Just don't be
>>> in business against them if being a few milliseconds slower on the
>>> uptake means money lost.
>>
>> so now you are saying that you are faster then a ramdisk?????
>
> No, I am saying that my driver is faster than any script you can write.
> Your script will not be able to give access to data while the ramdisk
> is being populated, nor will it be able to save efficiently exactly
> what is dirty in the ramdisk.  (Explained in my original post if you
> would like to take a look.)

that is not something that makes a difference of a few milliseconds

>> if you have a reliable UPS and are willing to rely on it to save your data
>> take the identical hardware to what you are planning to use, but instead
>> of using your driver just create a ramdisk and load it on boot and save
>> the contents on shutdown.
>
> Aha!  You are getting close.  Really, that is all ramback does.  It
> just handles some very difficult related issues efficiently, in such a
> way as to minimize any denial of service from complete loss of UPS
> power.  This is all just about using power management in a new way that
> gets higher performance.  But your battery power has to be reliable.
> Just make it so.  It is not difficult these days, or even particularly
> expensive.
>
> I calculated somewhere along the line that it would take something like
> 17 minutes to populate the big Violin ramdisk initially, and 17 minutes
> to save it during a loss of line power event, during which UPS power
> must be not run out before ramback achieves disk sync or you will get
> file corruption.  (This rule was mentioned in my original post.)
>
> All well and could, you can in fact do that with a pretty simple script.
> But in the initial 17 minutes your application may not read or write
> the ramdisk data and in the closing 17 minutes it may not write.  That
> knocks your system down to 4 nines, given one planned shutdown per year.
> Not good, not good at all.
>
> See, ramback is entirely about _not_ getting knocked down to 4 nines.
> It wants to stay above 6, given system components that satisfy that goal,
> comprising:
>
>  * Linux
>  * Processor, memory, motherboard etc
>  * Dual power supplies with independent UPS backup
>  * Ramback driver
>
> 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.

> 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, 
since your system will loose massive amounts of data if they happen. 
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.

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