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: <200803161639.12555.phillips@phunq.net>
Date:	Sun, 16 Mar 2008 15:39:11 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Willy Tarreau <w@....eu>, David Newall <davidn@...idnewall.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

On Sunday 16 March 2008 15:46, Alan Cox wrote:
> > Hostility does not equate to accuracy.  Galileo comes to mind.
> 
> I see no attempt to even discuss the use of two sets
> of physical storage to maintain coherent snapshots, just comments about
> hostility. That's a fairly poor way to repay people who spend a lot of
> time working with enterprise customers and are interested in solutions
> using things like giant ramdisks and are putting in time to discuss
> alternative ways of achieving the desired result.

You did not explain how your proposal will avoid dropping the transaction
throughput down to disk speed, whereas I have explained how my existing
design can be made to achieve enterprise-grade data safety.

As far as I can see, there is no way to do what you propose without
losing a couple of orders of magnitude of transaction response time
under normal running conditions.  If you can see a method that I cannot,
then I am all ears.  Until then... I just loved the earlier post to the
thread:

  "It is not the best way to travel faster than light.  It is just
  the only way".

I do not think you have set out to solve the same problem I have, which
is to attain the highest possible transaction throughput with enterprise
scale reliability.  If you would like to take my code and modify it to
work just as you wish it, then of course you are more than welcome.

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/