linux-kernel - Re: [ANNOUNCE] Ramback: faster than a speeding bullet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47DEBEEA.3060900@davidnewall.com>
Date:	Tue, 18 Mar 2008 05:26:42 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Daniel Phillips <phillips@...nq.net>
CC:	david@...g.hm, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org
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.
--
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/