1. 09 Oct, 2018 1 commit
  2. 13 Jul, 2018 1 commit
  3. 22 Jun, 2018 1 commit
  4. 05 Jan, 2018 1 commit
  5. 13 Oct, 2017 1 commit
  6. 16 Apr, 2017 1 commit
    • Javier González's avatar
      lightnvm: physical block device (pblk) target · a4bd217b
      Javier González authored
      This patch introduces pblk, a host-side translation layer for
      Open-Channel SSDs to expose them like block devices. The translation
      layer allows data placement decisions, and I/O scheduling to be
      managed by the host, enabling users to optimize the SSD for their
      specific workloads.
      
      An open-channel SSD has a set of LUNs (parallel units) and a
      collection of blocks. Each block can be read in any order, but
      writes must be sequential. Writes may also fail, and if a block
      requires it, must also be reset before new writes can be
      applied.
      
      To manage the constraints, pblk maintains a logical to
      physical address (L2P) table,  write cache, garbage
      collection logic, recovery scheme, and logic to rate-limit
      user I/Os versus garbage collection I/Os.
      
      The L2P table is fully-associative and manages sectors at a
      4KB granularity. Pblk stores the L2P table in two places, in
      the out-of-band area of the media and on the last page of a
      line. In the cause of a power failure, pblk will perform a
      scan to recover the L2P table.
      
      The user data is organized into lines. A line is data
      striped across blocks and LUNs. The lines enable the host to
      reduce the amount of metadata to maintain besides the user
      data and makes it easier to implement RAID or erasure coding
      in the future.
      
      pblk implements multi-tenant support and can be instantiated
      multiple times on the same drive. Each instance owns a
      portion of the SSD - both regarding I/O bandwidth and
      capacity - providing I/O isolation for each case.
      
      Finally, pblk also exposes a sysfs interface that allows
      user-space to peek into the internals of pblk. The interface
      is available at /dev/block/*/pblk/ where * is the block
      device name exposed.
      
      This work also contains contributions from:
        Matias Bjørling <matias@cnexlabs.com>
        Simon A. F. Lund <slund@cnexlabs.com>
        Young Tack Jin <youngtack.jin@gmail.com>
        Huaicheng Li <huaicheng@cs.uchicago.edu>
      Signed-off-by: default avatarJavier González <javier@cnexlabs.com>
      Signed-off-by: default avatarMatias Bjørling <matias@cnexlabs.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a4bd217b
  7. 31 Jan, 2017 1 commit
    • Matias Bjørling's avatar
      lightnvm: merge gennvm with core · ade69e24
      Matias Bjørling authored
      For the first iteration of Open-Channel SSDs, it was anticipated that
      there could be various media managers on top of an open-channel SSD,
      such to allow vendors to plug in their own host-side FTLs, without the
      media manager in between.
      
      Now that an Open-Channel SSD is exposed as a traditional block device,
      there is no longer a need for this. Therefore lets merge the gennvm code
      with core and simplify the stack.
      Signed-off-by: default avatarMatias Bjørling <matias@cnexlabs.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      ade69e24
  8. 21 Sep, 2016 1 commit
    • Geert Uytterhoeven's avatar
      lightnvm: NVM should depend on HAS_DMA · e105ddb4
      Geert Uytterhoeven authored
      If NO_DMA=y:
      
          drivers/built-in.o: In function `nvme_nvm_dev_dma_free':
          lightnvm.c:(.text+0x23df1a): undefined reference to `dma_pool_free'
          drivers/built-in.o: In function `nvme_nvm_dev_dma_alloc':
          lightnvm.c:(.text+0x23df38): undefined reference to `dma_pool_alloc'
          drivers/built-in.o: In function `nvme_nvm_destroy_dma_pool':
          lightnvm.c:(.text+0x23df4c): undefined reference to `dma_pool_destroy'
          drivers/built-in.o: In function `nvme_nvm_create_dma_pool':
          lightnvm.c:(.text+0x23df7e): undefined reference to `dma_pool_create'
      
      and
      
          ERROR: "dma_pool_destroy" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_free" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_alloc" [drivers/nvme/host/nvme-core.ko] undefined!
          ERROR: "dma_pool_create" [drivers/nvme/host/nvme-core.ko] undefined!
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      e105ddb4
  9. 07 Jul, 2016 1 commit
  10. 07 Dec, 2015 1 commit
  11. 29 Oct, 2015 3 commits
    • Matias Bjørling's avatar
      rrpc: Round-robin sector target with cost-based gc · ae1519ec
      Matias Bjørling authored
      This target allows an Open-Channel SSD to be exposed asas a block
      device.
      
      It implements a round-robin approach for sector allocation,
      together with a greedy cost-based garbage collector.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      ae1519ec
    • Matias Bjørling's avatar
      gennvm: Generic NVM manager · 48add0f5
      Matias Bjørling authored
      The implementation for Open-Channel SSDs is divided into media
      management and targets. This patch implements a generic media manager
      for open-channel SSDs. After a media manager has been initialized,
      single or multiple targets can be instantiated with the media managed as
      the backend.
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      48add0f5
    • Matias Bjørling's avatar
      lightnvm: Support for Open-Channel SSDs · cd9e9808
      Matias Bjørling authored
      Open-channel SSDs are devices that share responsibilities with the host
      in order to implement and maintain features that typical SSDs keep
      strictly in firmware. These include (i) the Flash Translation Layer
      (FTL), (ii) bad block management, and (iii) hardware units such as the
      flash controller, the interface controller, and large amounts of flash
      chips. In this way, Open-channels SSDs exposes direct access to their
      physical flash storage, while keeping a subset of the internal features
      of SSDs.
      
      LightNVM is a specification that gives support to Open-channel SSDs
      LightNVM allows the host to manage data placement, garbage collection,
      and parallelism. Device specific responsibilities such as bad block
      management, FTL extensions to support atomic IOs, or metadata
      persistence are still handled by the device.
      
      The implementation of LightNVM consists of two parts: core and
      (multiple) targets. The core implements functionality shared across
      targets. This is initialization, teardown and statistics. The targets
      implement the interface that exposes physical flash to user-space
      applications. Examples of such targets include key-value store,
      object-store, as well as traditional block devices, which can be
      application-specific.
      
      Contributions in this patch from:
      
        Javier Gonzalez <jg@lightnvm.io>
        Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
        Jesper Madsen <jmad@itu.dk>
      Signed-off-by: default avatarMatias Bjørling <m@bjorling.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      cd9e9808