As a UNIX veteran who has a vague recollection of /dev/drum, I keep thinking that it would be really nice to have a device to swap to that's somewhere between disk and memory in terms of speed and cost (total installed cost, not just each module).
Mostly, I feel constrained by the 32-48GB limits on moderately priced ($1-3k) servers. To go higher, for even modest processor speeds, is a $5-$10k premium. Moreover, DRAM doesn't really wear out, and it would be nice to put older, lower density modules to use.
The trouble is, what I've found so far is either very low capacity, priced much higher than the memory modules themselves, or both. I'm not particularly interested in adding 4GB of fast swap to a 48GB machine, though ACARD has something for $250 with a 48GB limit, with high density modules, defeating my second purpose. Similarly, I'm not interested in paying $10k for 16GB of RAM SSD ($625/GB?!) when I could just dump that money into the base server and get much faster access.
I'm not a hardware guy (in the EE sense), so I'm genuinely curious about this. Is it really that difficult/expensive to stick a memory controller (northbridge?) onto a SATA interface? Am I being too cynical in assuming that it's mere market "segmentation" without a low-end consumer segment?
What I described already exists with the name "motherboard," but the software package "scst" seems woefully incomplete. For example, the MPT-Fusion driver is still described as "alpha" or early development, so I'm not holding my breath on reliability, let alone performance. I'm sure participation by the vendors would help. LSI, are you listening?
Subscribe to this comment's feed
written by Storage Girl, June 16, 2009
-
- +1
-
-
written by Max Kalashnikov, June 16, 2009
-
- +0
-
-
written by Storage Girl, June 20, 2009
-
- +0
-
-
written by Edoardo Daelli, June 24, 2009
PCI -> SATA -> DRAM controller so your OS can talk SATA to a DRAM module?
Is that correct??
If so, I dont think I have ever heard of such controller, but I will ask around and see if anybody listens!!!! ;-)
-
- +0
-
-
written by Max Kalashnikov, June 24, 2009
PCI->SAS->expander->SATA->DIMMslot->standardDIMM
Of course, it's the last three steps which are key. My last paragraph suggests that I'm willing to roll my own SAS->DIMMs device by using a server box. I'm just missing two things:
(1) a PCIe SAS HBA that acts as a target rather than an initiator
(2) a Linux driver for the above (that, ideally, allows me to map any files or block devices to any LUNs or WWNs, but I'd settle for just a configurable amount of system memory)
I suppose (2) wouldn't even have to be a Linux driver but could be the entire OS, using the entirety of available memory.
Even if a vendor charged an exorbitant $1k for (1), that means a 32GB (volatile) DRAM SSD could cost only $2k above the DIMMs themselves, or $5k total with cheapish memory, an attractive proposition. Off-brand cases, mobos, and memory could halve the price or double the maximum capacity, even more attractive.
-
- +1
-
-
written by Edoardo Daelli, June 24, 2009
It is not exactly what you describe, but pretty close, and the difference for your purposes won't matter:
PCIe -> SAS -> Expander -> SAS (Not SATA) -> OS -> DIMMslot -> StandardDIMM
There are HBA's out there that can be configured to be an SSP target.
The problem is that I am not sure one can buy such HBAs, configure them to be SSP targets, and get a hold of the API to write the software that uses memory for LUNs.
Unless you are a big OEM, with an NDA, and buying a billion HBA's! :-)
-
- +0
-
-
written by Max Kalashnikov, June 24, 2009
I don't, after all, want an API encumbered by an NDA. I want a shrink-wrapped box with a product.
Granted, the market may be too small for the likes of LSI to be interested in shrink-wrapping, as seems to be the case for SAS expanders. Perhaps I should be asking HP, SuperMicro, and/or Chenbro to listen.
-
- +0
-
-
