It makes a difference of degree, not of kind.
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.
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
--
