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]

Date:	Wed, 12 Mar 2008 22:17:20 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	David Newall <davidn@...idnewall.com>
Cc:	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 Wednesday 12 March 2008 22:45, David Newall wrote:
> Daniel Phillips wrote:
> > So you design for the number of nines you need, taking all factors
> > into account, and you design for the performance you need.  These are
> > cut and dried calculations.  FUD has no place here.
> 
> There's no FUD here.  The problem is that you didn't say that you've
> designed this for only a few nines.

Right.  6 or 7.

> If you delete fsck from your 
> rationale, simply saying that you rely on UPS to give you time to flush
> buffers, you have a much better story.  Certainly, once you've flushed
> buffers and degraded to write-through mode, you're obviously as reliable
> as ext2/3.

Fsck was never a part of my rationale.  Only reliability of components
was and is.  Then people jumped in saying Linux is too unreliable to
use in a, hmm, storage system.  Or transaction processing system.  Or
whatever.

Balderdash, I say.

> Your idea seems predicated on throwing large amounts of RAM at the
> problem.  What I want to know is this: Is it really 25 times faster than
> ext3 with an equally huge buffer cache?

Yes.

Regards,

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/