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:	Sat, 15 Mar 2008 14:00:05 -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 Saturday 15 March 2008 14:03, Alan Cox wrote:
> > > RAID controllers do not have half a terabyte of RAM.
> > 
> > And?  Either you have battery backed ram with critical data in it or
> > you do not.  Exactly how much makes little difference to the question.
> 
> It makes a lot of difference,

It makes a difference of degree, not of kind.

> and in addition raid controllers (good 
> ones) respect barrier ordering in their RAM cache so they'll take tags or
> similar interfaces and honour them.

Ramback should obviously respect barriers, and it does, though at
present only in the crude, default way of letting the block layer
handle it.

But interpreting a barrier to mean flush through to rotating media...
performance will drop to the millisecond per transaction zone, like a
normal disk.  Not what ramback users want in normal operating mode.
Flush mode, yes.

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?

"Some raid controllers" is just as good for my argument as "all raid
controllers".  Nobody is telling you which raid controller to use in
your own personal system.  I will pick the fast one and you can pick
the slow one that does not trust its own battery circuits.

> > That is why I keep recommending that a ramback setup be replicated or
> > mirrored, which people in this thread keep glossing over.  When
> > replicated or mirrored, you still get the microsecond-level transaction
> > times, and you get the safety too.
> 
> Either you keep a mirror in sync and get normal data rates or you keep
> the mirror out of sync and then you need to sort your writeback process
> out to preserve ordering.
> 
> If you want ramback to be taken seriously then that is the interesting
> problem to solve and clearly has multiple solutions if you would start to
> take an objective look at your work.

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

Anyway, please do not get the impression that I am ignoring your ideas.
There are some nice, intermediate modes that ramback could and in my
opinion, should implement, to give users more options on how to trade
off performance against resilience.  I just need to make it clear that
ramback, as conceived, already gives system builders the capability
they need to achieve microsecond level transaction throughput and data
safety at the same time... given a reliable battery, which is where we
started.

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/