It wouldn't be TOO hard to get some small FPGA or microcontroller, wire it to a set of flash chips, and hook that to a PCIe bus. Then we'd want to use something like NILFS2 as the filesystem to handle wear-leveling in software.
We can just expose the raw flash organization to the host so that the host software can allocate blocks and schedule accesses to individual flash chips. So we'd likely need a specialized filesystem that reorders requests so that blocks are pulled from as many chips as possible at once for maximum throughput. It would also have to handle block remapping, garbage collection, etc. We'd just put an accessible ROM on there that lays out the structure for the kernel driver. On Wed, Dec 12, 2012 at 12:03 PM, "Ing. Daniel Rozsnyó" <[email protected]>wrote: > It does not need to be equipped with SST-RAM, having a nice opensource SSD > would be something I would buy - if the openness of it can show the reality > (about block erase count, errors to be found) and it would do what us - the > users want (more conservative behaviour rather than insane speeds). > > My first experience with SSD's was in my wife's laptop (I thought the SSD > will bear better the use in). Her drive after 3 months of normal use > stopped working - the fail led is lit and the drive is no longer recognized > by the computer. > > After little discussion with the drive/chip manufacturers (OCZ and > Sandforce), where both are claiming the issue to be due to opposite side > and none of them was able to supply any documentation... so I ended up with > 16 nand flash devices to experiment with :) > > On the contrary to that, Micron as the actual chip maker behaves very > nicely and I think if we start making SSD (on the open-hardware part of the > movement), we could get more market share than with GPUs (in the > short-term). And that is even if we make a plain storage with no wear > levelling (and delegate that to BTRFS or similar intelligent filesystem). > > What does other think? > > > > > On 12/12/2012 05:36 PM, Timothy Normand Miller wrote: > >> All true. But exotic RAM devices are a hot topic and something I might >> be able to get funding to work on. What would be great is if we could >> turn that into something like a fast open source SSD. Could be a long >> time, though, but STT-RAM devices have been produced. >> >> Areas to innovate: >> - Block erasure, mapping, and access scheduling algorithms >> - Error correcting codes >> - Host interfaces >> - We should look at conference proceedings for other stuff >> >> STT-RAMs don't require wear-leveling. >> >> >> >> >> On Wed, Dec 12, 2012 at 12:44 AM, Jack Carroll <[email protected] >> <mailto:[email protected]>**> wrote: >> >> For a non-volatile memory, that's fast. But a framebuffer doesn't >> need nonvolatile memory. >> >> Jack Carroll >> >> ----- Original Message ----- >> From: "Dieter BSD" <[email protected] >> <mailto:[email protected]**>> >> To: [email protected] >> <mailto:open-graphics@**duskglow.com<[email protected]> >> > >> Sent: Tuesday, December 11, 2012 3:37:09 PM >> Subject: [Open-graphics] low power, non-volatile memory >> >> Slightly off-topic, but we are going to be needing memory. >> >> spin transfer torque magnetoresistive random access memory (STT-MRAM) >> >> "improved speed while reducing power consumption by 90%" >> >> Less power than SRAM and non-volatile. But...I must be reading the >> graph >> wrong, looks like 300ns? Isn't that obscenely slow for 2012? Also >> isn't clear if they have actually built and tested it or just >> simulated it. >> >> http://www.xbitlabs.com/news/**memory/display/20121210213212_** >> Toshiba_s_STT_MRAM_Memory_**Element_Promises_World_s_Best_** >> Power_Consumption.html<http://www.xbitlabs.com/news/memory/display/20121210213212_Toshiba_s_STT_MRAM_Memory_Element_Promises_World_s_Best_Power_Consumption.html> >> ______________________________**_________________ >> Open-graphics mailing list >> [email protected] >> <mailto:Open-graphics@**duskglow.com<[email protected]> >> > >> >> http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics> >> List service provided by Duskglow Consulting, LLC (www.duskglow.com >> <http://www.duskglow.com>) >> ______________________________**_________________ >> Open-graphics mailing list >> [email protected] >> <mailto:Open-graphics@**duskglow.com<[email protected]> >> > >> >> http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics> >> List service provided by Duskglow Consulting, LLC (www.duskglow.com >> <http://www.duskglow.com>) >> >> >> >> >> -- >> Timothy Normand Miller, PhD >> Assistant Professor of Computer Science, Binghamton University >> http://www.cs.binghamton.edu/~**millerti/<http://www.cs.binghamton.edu/~millerti/> >> <http://www.cse.ohio-state.**edu/~millerti<http://www.cse.ohio-state.edu/~millerti> >> > >> Open Graphics Project >> >> >> >> ______________________________**_________________ >> Open-graphics mailing list >> [email protected] >> http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics> >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> >> ______________________________**_________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics> > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller, PhD Assistant Professor of Computer Science, Binghamton University http://www.cs.binghamton.edu/~millerti/<http://www.cse.ohio-state.edu/~millerti> Open Graphics Project
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
