Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Friday September 06 2019, @01:41AM   Printer-friendly

Samsung Announces Standards-Compliant Key-Value SSD Prototype

Samsung has announced a new prototype key-value SSD that is compatible with the first industry standard API for key-value storage devices. Earlier this year, the Object Drives working group of Storage Networking Industry Association (SNIA) published version 1.0 of the Key Value Storage API Specification. Samsung has added support for this new API to their ongoing key-value SSD project.

Most hard drives and SSDs expose their storage capacity through a block storage interface, where the drive stores blocks of a fixed size (typically 512 bytes or 4kB) and they are identified by Logical Block Addresses that are usually 48 or 64 bits. Key-value drives extend that model so that a drive can support variable-sized keys instead of fixed-sized LBAs, and variable-sized values instead of fixed 512B or 4kB blocks. This allows a key-value drive to be used more or less as a drop-in replacement for software key-value databases like RocksDB, and as a backend for applications built atop key-value databases.

Key-value SSDs have the potential to offload significant work from a server's CPUs when used to replace a software-based key-value database. More importantly, moving the key-value interface into the SSD itself means it can be tightly integrated with the SSD's flash translation layer, cutting out the overhead of emulating a block storage device and layering a variable-sized storage system on top of that. This means key-value SSDs can operate with much lower write amplification and higher performance than software key-value databases, with only one layer of garbage collection in the stack instead of one in the SSD and one in the database.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Interesting) by shrewdsheep on Friday September 06 2019, @07:27AM (1 child)

    by shrewdsheep (5215) on Friday September 06 2019, @07:27AM (#890429)

    LBA has always been an abstraction (spare sectors, physical structure etc). Even in the Head/Cylinder/Sector-days this addressing got abstracted because outer cylinders could hold more sectors than inner ones (software compatibility through hardware changes).
    Maybe such drives can also be efficient files systems with the key being the inode and the value the file content. A minimal software layer would be needed to handle folders and meta-data therein. Such a file system would not have any file count limitation as keys can just become larger when needed.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Friday September 06 2019, @07:59AM

    by Anonymous Coward on Friday September 06 2019, @07:59AM (#890437)

    Yeah, I know about ZBR, and CHS 1023/255/63 limits, and internal controllers mapping before any of that was even a concern. But, this could be a good file system support underneath. Just map directly like you suggest. Heck, I know many pieces of software that already store files like this in databases. I'll have to give the specification a good read and watch the mailing lists and give LWN a search in a few months.