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: <20080315230558.12e9c96c@the-village.bc.nu>
Date:	Sat, 15 Mar 2008 23:05:58 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Willy Tarreau <w@....eu>, David Newall <davidn@...idnewall.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet

> > It makes a lot of difference,
> 
> It makes a difference of degree, not of kind.

I think "I get my data back" is a difference in kind.

> But interpreting a barrier to mean flush through to rotating media...
> performance will drop to the millisecond per transaction zone, like a

That isn't anything to do with what was being proposed. *ORDERING* not
flush to media.

> Even raid controllers... so you agree that some of them just don't
> respond conservatively to tagged commands, either because the engineers
> don't know how to implement that (unlikely) or because they want to win
> the performance benchmarks, and they do trust their battery?

The ones that don't respect tagged ordering are the ultra cheap nasty
things you buy down the local computer store that come with a 2 page
manual in something vaguely like English. The stuff used for real work is
quite different.

> Ramback already is taken seriously, just not by you.  That is fine, you
> apparently do not need or want the speed.

I want the speed and reliability. Without that ramback is a distraction
until someone solves the real problems.

> they need to achieve microsecond level transaction throughput and data

You have no guarantee of commit to stable storage so your use of the word
"transaction" is a bit farcical.

There are a whole variety of ways to get far better results than "whoops
bang there goes the file system". Log structured backing media is one,
even snapshots. That way you'd quantify that for the cost of more
rotating storage (which is cheap) you can only lose "x" minutes of data
and will lose everything from a defined consistent point. File based
backing store also has similar properties done right, but needs some
higher level care to track closure and dirty blocks on a per inode basis.

Alan
--
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/