Messages in this thread | | | Date | Tue, 18 Mar 2008 05:26:42 +1030 | From | David Newall <> | Subject | Re: [ANNOUNCE] Ramback: faster than a speeding bullet |
| |
Daniel Phillips wrote: > On Monday 17 March 2008 00:14, David Newall wrote: > >> 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. >> > > You are twisting words.
I don't think so.
> I may have said that replication provides a > point-in-time copy of a volume, which is exactly what it does, no more, > no less. >
You said that you could achieve a certain performance, and later you said that for reliability you could use mirroring and replication but you never said that would lead to a performance hit. In fact you don't seem to be able to offer performance AND robustness; for performance you can only offer that level of robustness attainable on a single system, which means I think even you agreed was really not up to snuff for customers who would need the performance that you claim to achieve.
>> 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. >> > > A big buffer cache does not provide a guarantee that the dirty cache > data saved to disk when line power is lost. But the filesystem does offer a minimum level of consistency, which is missing from what you propose. You propose writing nothing unless line-power fails. The big buffer cache gives you all of the robustness of the underlying filesystem and including dirty buffer writes at some level greater than zero.
> If you just want to > explain to me one more time that Linux, batteries, whatever, cannot > be relied on, then please do not include me in the CC list.
I haven't said that at all, other than as an axiom (which even you have agreed is fair) leading to comments on the results when something does fail. You keep saying that it won't ever fail, then that it will but that you can mitigate using redundant systems; and then you gloss over or refuse to face the attendant performance hit. Finally, you still have no idea whether your idea really does achieve a massive performance boost. You've never compared like amounts of RAM, nor the unsynced updates that most closely resemble your idea. In short, you've leaped on what seems to you to be a good idea and steadfastly refused to conduct even basic research. What's the point?
You say don't cc you; I say go away, do that basic research, and come back when you have hard data. I really don't think you can ask for fairer than that.
| |