How to use a terabyte of RAM
Perhaps it's time for some wild ideas. And there is no better source for
such ideas than Daniel Phillips, whose Ramback patch has stirred up a
bit of discussion this week. The core idea behind Ramback is that all of
that memory is turned into a ramdisk, but with a persistent device attached
to it. In normal conditions, all application I/O involves only the
ramdisk, and is, thus, quite fast ("Every little factor of 25
performance increase really helps.
"). In the background, the kernel
worries
about synchronizing data from the ramdisk onto permanent storage. But the
synchronization process is mostly concerned with I/O performance, rather
than providing guarantees about just when any given block will make it onto
the disk platters.
Ramback thus differs from the normal block I/O caching done by the kernel in a number of ways. It keeps the entire device in memory, so that, in steady-state operation, applications need never encounter a disk I/O delay. Should an application call fsync(), the expected result (blocking until the data is written to physical media) will not happen. Filesystems take great care to order operations in a way that minimizes the risk of data loss in a crash; Ramback ignores all of that and writes data to physical media in whatever order it decides is best. As Daniel put it, the "most basic principle" of Ramback's design is:
Ramback does include an emergency mode which will endeavor to bring the disk up to date in a hurry should the UPS indicate that power has been lost. But that does not seem to be enough for everybody. In the resulting discussion, nobody complained about the sort of performance benefits that a tool like Ramback could provide. But there was a lot of concern about data integrity; it seems that many people distrust their battery, their hardware, and Linux. And that has led to a sort of impasse, with several developers claiming that Ramback would be too risky to use and Daniel dismissing their concerns as FUD.
FUD or not, those concerns are likely to be a difficult barrier for Ramback to overcome. Meanwhile, Daniel is looking for people to help test out the code, but that presents challenges of its own:
So far, reports from suitably courageous testers have been, well, scarce.
Your editor fears that this work could suffer the same fate as many of
Daniel's other patches: they can contain brilliant ideas and great coding
but just don't quite survive the encounter with the real, messy world.
But we need people thinking about how our systems will work in the
coming years; one hopes that Daniel won't stop.
| Index entries for this article | |
|---|---|
| Kernel | Block layer/Block drivers |
| Kernel | Ramback |