On Thursday 13 March 2008 09:25, david@lang.hm wrote:
The period where you cannot access the data is downtime. If your script
just does a cp from a disk array to the ram device you cannot just read
from the backing store in that period because you will need to fail over
to the ramdisk at some point, and you cannot just read from the ramdisk
because it is not populated yet. My point is, you cannot implement
ramback as a two line script and expect to achieve anything resembling
continuous data availability.
I interpret your point about the script as, Ramback is trivial and easy
to implement. That is kind of true and kind of untrue, because of the
additional requirements mentioned in my original post.
Never is not the right word, but indeed that is why I wrote the story
about the rocket ship. If you want the performance that ramback
delivers then you cover the risk of hardware failure by other,
standard means.
Why would you assume the data is not mirrored or replicated with a
short cycle, or no other suitable fallback plan is in place?
All true. Now what about the punchcard versus magnetic media story?
There was a time when magnetic domains were considered less reliable
than holes in paper cards, ironically we now think the opposite. So
some people will have a hard time with the idea that a battery is
reliable enough to get your important cached data on to hard disk when
necessary, or that Linux is reliable enough to trust data to it, or
whatever. They will get over it. Battery backed data will become a
normal part of your life as progress marches on.
Daniel
--
