5 ms·

Could you make money by producing a cheap "dumb" flash memory where you have raw access and leave all the wear leveling to software by using one of the many ava

• duskwuff 6y ago
  Unlikely. The cost savings probably wouldn't be as dramatic as you hope. You'd still need some sort of controller for serdes -- NAND flash chips tend to use big parallel busses which aren't suited for off-board connectors -- and, at that point, it's not that much of a jump to make that controller handle wear leveling and error correction. (Having the storage device handle those tasks is pretty convenient, anyways. It means you don't have to perform error correction on the main CPU -- which is a nontrivial ask -- and it means the SSD can behave as a bootable device.)
  • londons_explore 6y ago
    Wear levelling and error correction are pretty different problems. Error correction is well suited to hardware, whereas wear levelling in my opinion is not. My ideal design would have basic hardware error detection and correction (hopefully configurable for how many data bits Vs ECC bits), and maybe with a few heirarchical levels. Wear levelling and management of data layouts would all be done in software. You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read.
    • st_goliath 6y ago
      > You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read. There are a lot of existing SoCs that have built in flash controller hardware that can interface with an external flash chip and, from a driver perspective, are controlled pretty much the way you describe it.
  • sprash 6y ago
    The margins on flash media are razor thin already. This is a high volume operation where subcents per unit count. If you can shave off a little more by using a dumb controller that does not contain any IP that needs to be licensed it is very easy to calculate how high the volume has to be in order to be profitable.
    • duskwuff 6y ago
      Consider that Olympus/Fujifilm tried this in the early 2000s with XD-Picture Card. (The cards were literally just a NAND flash chip wired up to the pins.) Even though this theoretically reduced the BOM cost for the cards, XD lost in the market to other solutions like Compact Flash and SD, which embedded a controller.
      • sprash 6y ago
        xD failed because it was a proprietary standard used exclusively by FujiFilm and Olympus and were generally more expensive to the consumers than the completely open and free SD-format. The lack of a flash translation layer was a major advantage.
• pjc50 6y ago
  I don't think you could unless you had a flagship customer using it in a huge data centre. You'd need to write a "reference design" filesystem for it anyway. Since volume is so important in electronics, you'd need to scale up a lot in order to make it cost-effective. Amazon, Google, Microsoft and Apple are in a position to do this for their cloud offerings, but so far as I can tell they haven't. Which tells you it's probably not cost effective. (I think there are benefits to be had from giving even local storage a "blob" interface, as you reduce the amount of random writes, but we're not there yet)
  • londons_explore 6y ago
    > Amazon, Google, Microsoft and Apple are in a position to do this for their cloud offerings, but so far as I can tell they haven't. At least 2 of those named companies have their own mostly-software-controlled SSD designs.
• zozbot234 6y ago
  > Could you make money by producing a cheap "dumb" flash memory where you have raw access The problem is that low-level or "raw" access to flash is not that well-defined and not "cheap" or "dumb" at all. SD cards and eMMC storage are cheap and use very baseline FTL's, but what they provide is far from "low-level" access - you can't even erase a block and write sub-blocks on it individually, which is the basic operation in any flash translation layer.
  • londons_explore 6y ago
    Most SD cards do have debug ways to read and write raw flash... Just they're undocumented and manufacturer specific, so you probably wouldn't want to use them in a shipping product.
• st_goliath 6y ago
  FYI: This is already a thing in the embedded world and Linux already has corresponding software infrastructure: The "mtd" subsystem which stands for "memory technology devices" is a thin hardware abstraction layer for primarily raw flash devices with an internal framework for NAND flash with driver backends for all sorts of controlers and devices and support for e.g. software error correction if the device/controller doesn't support it, etc... The "ubi" subsystem which provides wear-leveling, bad block management and LVM style logical volume partitioning on top of mtd. It does not emulate a normal block device, it acts more like a flash device with idealized properties. The "ubifs" file system which was specifically designed for working on top of ubi. If you try to use this stack on a large-ish scale to build a DIY Linux powered SSD, you might run into scaling problems with ubi tough (don't think some companies haven't tried that yet). While it basically works, as always, pretty much every flash vendor guards the inner workings of their devices as secrets and those things have undocumented quirks and undocumented, secret instructions to work around various quirks used by the companies own SSDs and eMMCs. > Could you make money by producing a cheap "dumb" flash memory where you have raw access and leave all the wear leveling to software by using one of the many available log structured file systems? Technically, the market exists, but whether you could get into it and make money is another question. I'm willing to bet that if you design a NAND flash from scratch and try to sell it, the existing vendors will clobber you with patent infringement law suits. AFAIK the reasons why Linux has ubi instead of a full, in-kernel flash translation layer are also legal ones.
  • tenebrisalietum 6y ago
    Most Linux-based home routers (which means most routers) have raw access to flash. If you ever just wanted to play with it you can just find some old router out of a local thrift shop, check if it can handle a DD-WRT or OpenWRT, then experiment. You just have to be careful because the bootloader and NVRAM partitions are crucial to the device booting. Serious experimenters would find the serial port header pins and have a working serial port.
    • duskwuff 6y ago
      Most home routers use serial NOR flash, not NAND flash. Lower capacity, but easier to interface with. No wear leveling is supported or required, as the expected write count is much lower than the endurance of the device.
• pram 6y ago
  Isn't this how the Apple SSDs work with the T2 chip?
  • wtallis 6y ago
    The T2 chip contains the functionality of a somewhat non-standard NVMe SSD controller, so the x86 CPU running macOS has pretty much the same responsibilities as when dealing with an off the shelf SSD.
• Veedrac 6y ago
  The main abstraction costs are excess DRAM and overprovisioning, and those don't come from wear levelling but the block abstraction layer (aka. pretending to support random writes). So where there used to be a buzz around ‘open-channel SSDs’, that give a lot of this control and responsibility to the host, but often just meant the host is absorbing all those costs, the hot new thing is ‘zoned namespaces’, which keep wear levelling on the host, but provide an API without totally random writes that maps well to hardware, and that seems to be a much better trade-off.
  • wtallis 6y ago
    Flash can support random writes, but not overwrites. The zoned namespaces abstraction is a little bit more restrictive than is necessary for SSDs, but it's being developed that way so that the same abstraction can also be used with SMR hard drives.
    • Veedrac 6y ago
      ZNS does support random writes to the uncommitted blocks at the head of a zone.
      • wtallis 6y ago
        I'm not sure what you're trying to say there. My understanding is that each zone is append-only, which definitely isn't how flash erase blocks work.
        • Veedrac 6y ago
          They're not quite append only, there's a ‘zone random write area’ that you can update in-place that exposes the write buffer in front of a zone. To a lesser degree, it also supports parallel appends, which naturally aren't purely sequential either. So you've got random writes both between zones and at the front of each zone. The one thing missing is being able to erase blocks within the committed portion of a zone, but idk how you'd support that without just reimplementing a block layer.
• jrockway 6y ago
  I have always wanted to do this. I would much rather manage redundancy and error correction at the application level, so that the application has a good idea of what data is being lost well in advance of it being gone for good. The idea of having some chip with software that I've never seen in charge of this seems crazy to me. You can look at how much data people lose on SD cards (every Raspberry Pi user will tell you they "go bad"); most of it is not loss of content on flash, but corruption from interrupting the internal MCU at a bad time. Remove that and use proper transactional writes, and they'd probably never instantly go bad. But, random write benchmarks would not look as good.
  • h2odragon 6y ago
    I did something like that long ago; stole md code and made my own raw block i/o routines where low cost data was raid0 and (re)generate it at need; but indexes and pointer tables were duplicated across all the spindles and even allowed greater parallelism. It was a lot of work; it had advantages but today it probably wouldnt be worth the effort.
• dannyw 6y ago
  So you can save something like $3 for a budget controller?
• pkaye 6y ago
  I used to do SSD firmware development. The raw flash is quite unreliable with many unideal behavior to work around. Also most of the cost is on the flash.