back to article Radian ready to replace the flash translation layer

Stealthy startup Radian Memory System's Symphonic software replaces an SSD's Flash Translation Layer software to accelerate performance up to 80 per cent and extend endurance. It's selling its own RMS-250 SSDs with this software for data centre use Flash Translation Layer (FTL) software enables a block-based SSD to be …

  1. Duncan Macdonald Silver badge

    Reliability ?

    With only a 3% overprovisioning, the life expectancy of this drive will be terrible. Once a few flash cells die (which they always do) the drive will end up underprovisioned. There is also a question (important for data centre use) about whether the drive can flush all out all outstanding writes (including metadata) in the event of a power failure.

    1. Anonymous Coward
      Anonymous Coward

      Re: Reliability ?

      I can't speak to the rest of the article but if you are running a data center without redundant power and battery backup besides, you should be taken out and shot. Sheesh!

  2. mtuber

    If it's that good

    why eMLC and not TLC or MLC

  3. Anonymous Coward
    Anonymous Coward

    Offloading the FTL functions to the host...

    ... ought to make this cheaper than a standard SSD.

    I bet it doesn't :-)

  4. Anonymous Coward
    Anonymous Coward

    Crazy Thought

    When I'm designing a computer one of the many things I like to pay attention to are what I liken to impedance mismatches. Gearing is another (mechanical) way of looking at this. It's why I'm big on the relationships between clock-cycles, latencies, etc. I get a nice little bump of improved performance when there isn't any slippage between different functional units in electronic devices. Relevant elsewhere, just not as "extreme" an example.

    What I'm seeing here, and wonder why no one has looked at it this way before surprises me, is matching the block size that the operating system and/or applications are using to the "natural" geometry of the flash memory itself rather than using 512 or 4K byte size that conventional hard drives present to the rest of the computer. It explains quite a bit of what is going on here, especially that 3% over-provisioning since what's required is quite a bit smaller than entire flash pages. There are other optimizations I can see which follow directly.

    Crazy, eh? {Shrug}

    1. Anonymous Coward
      Anonymous Coward

      Re: Crazy Thought

      It might use a more "native" block size for stuff like DBs, but you can't use a 64K block size (which is still smaller than flash's erase block size by more than an order of magnitude) for a typical filesystem (or VMFS that will contain many typical filesystems) without wasting a lot of space. Most files are small.

  5. Anonymous Coward
    Anonymous Coward

    Too easy to update driver software

    Putting all the smarts in the driver that runs on the host CPU that's far far higher performance than the controller running the FTL firmware sounds like a smart idea, except that you're now trusting a driver.

    Every time you patch your server, you'll probably be updating the driver, and definitely be updating the OS hooks the driver relies on. It is too tempting for Radian's engineers to keep tweaking for better performance or add features, etc. since you know people will update drivers. With firmware you only fix critical bugs because no one upgrades drive firmware other than to fix serious bugs (except in controlled environments like inside an enterprise array)

    I like the idea of keeping the FTL in firmware exactly because it is probably never going to be updated there, unless it is to fix a specific issue. You don't have to worry about patching your server and causing problems with the drive - worst case losing your data. I'm sure Radian will claim they take all sorts of steps to prevent this, but consider in both Linux and Windows there's no memory protection between drivers. If some other driver has a wild pointer and writes in the Radian driver's address space, goodbye data no matter how careful Radian is.

    I'll let others take the risk, and think about getting on board after suckers early adopters have baked it for a few years.

  6. Dr. Mouse


    FTL's were implements so we could just plug in an SSD and it works like a HDD. Great for simplicity, bad for extracting the best from the device. Filesystems are optimised for HDD-like access, but the FTL has to do a load of work to present flash like that, and will not be able to produce optimal results.

    What would be much better is a virtually raw interface to the flash, with a filesystem optimised for flash. This system looks to be attempting a half-way house. It's an interesting idea, although I still think an optimised FS would do a better job.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022