lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
#ifndef NVM_H
|
|
|
|
#define NVM_H
|
|
|
|
|
2016-07-07 01:54:16 -06:00
|
|
|
#include <linux/blkdev.h>
|
2016-01-13 13:04:11 -07:00
|
|
|
#include <linux/types.h>
|
2016-07-07 01:54:16 -06:00
|
|
|
#include <uapi/linux/lightnvm.h>
|
2016-01-13 13:04:11 -07:00
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
enum {
|
|
|
|
NVM_IO_OK = 0,
|
|
|
|
NVM_IO_REQUEUE = 1,
|
|
|
|
NVM_IO_DONE = 2,
|
|
|
|
NVM_IO_ERR = 3,
|
|
|
|
|
|
|
|
NVM_IOTYPE_NONE = 0,
|
|
|
|
NVM_IOTYPE_GC = 1,
|
|
|
|
};
|
|
|
|
|
2016-01-13 13:04:11 -07:00
|
|
|
#define NVM_BLK_BITS (16)
|
|
|
|
#define NVM_PG_BITS (16)
|
|
|
|
#define NVM_SEC_BITS (8)
|
|
|
|
#define NVM_PL_BITS (8)
|
|
|
|
#define NVM_LUN_BITS (8)
|
2016-05-06 12:03:19 -06:00
|
|
|
#define NVM_CH_BITS (7)
|
2016-01-13 13:04:11 -07:00
|
|
|
|
|
|
|
struct ppa_addr {
|
|
|
|
/* Generic structure for all addresses */
|
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
u64 blk : NVM_BLK_BITS;
|
|
|
|
u64 pg : NVM_PG_BITS;
|
|
|
|
u64 sec : NVM_SEC_BITS;
|
|
|
|
u64 pl : NVM_PL_BITS;
|
|
|
|
u64 lun : NVM_LUN_BITS;
|
|
|
|
u64 ch : NVM_CH_BITS;
|
2016-05-06 12:03:19 -06:00
|
|
|
u64 reserved : 1;
|
2016-01-13 13:04:11 -07:00
|
|
|
} g;
|
|
|
|
|
2016-05-06 12:03:19 -06:00
|
|
|
struct {
|
|
|
|
u64 line : 63;
|
|
|
|
u64 is_cached : 1;
|
|
|
|
} c;
|
|
|
|
|
2016-01-13 13:04:11 -07:00
|
|
|
u64 ppa;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_rq;
|
|
|
|
struct nvm_id;
|
|
|
|
struct nvm_dev;
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
struct nvm_tgt_dev;
|
2016-01-13 13:04:11 -07:00
|
|
|
|
|
|
|
typedef int (nvm_l2p_update_fn)(u64, u32, __le64 *, void *);
|
|
|
|
typedef int (nvm_id_fn)(struct nvm_dev *, struct nvm_id *);
|
|
|
|
typedef int (nvm_get_l2p_tbl_fn)(struct nvm_dev *, u64, u32,
|
|
|
|
nvm_l2p_update_fn *, void *);
|
2016-05-06 12:03:05 -06:00
|
|
|
typedef int (nvm_op_bb_tbl_fn)(struct nvm_dev *, struct ppa_addr, u8 *);
|
2016-05-06 12:03:09 -06:00
|
|
|
typedef int (nvm_op_set_bb_fn)(struct nvm_dev *, struct ppa_addr *, int, int);
|
2016-01-13 13:04:11 -07:00
|
|
|
typedef int (nvm_submit_io_fn)(struct nvm_dev *, struct nvm_rq *);
|
|
|
|
typedef int (nvm_erase_blk_fn)(struct nvm_dev *, struct nvm_rq *);
|
|
|
|
typedef void *(nvm_create_dma_pool_fn)(struct nvm_dev *, char *);
|
|
|
|
typedef void (nvm_destroy_dma_pool_fn)(void *);
|
|
|
|
typedef void *(nvm_dev_dma_alloc_fn)(struct nvm_dev *, void *, gfp_t,
|
|
|
|
dma_addr_t *);
|
|
|
|
typedef void (nvm_dev_dma_free_fn)(void *, void*, dma_addr_t);
|
|
|
|
|
|
|
|
struct nvm_dev_ops {
|
|
|
|
nvm_id_fn *identity;
|
|
|
|
nvm_get_l2p_tbl_fn *get_l2p_tbl;
|
|
|
|
nvm_op_bb_tbl_fn *get_bb_tbl;
|
|
|
|
nvm_op_set_bb_fn *set_bb_tbl;
|
|
|
|
|
|
|
|
nvm_submit_io_fn *submit_io;
|
|
|
|
nvm_erase_blk_fn *erase_block;
|
|
|
|
|
|
|
|
nvm_create_dma_pool_fn *create_dma_pool;
|
|
|
|
nvm_destroy_dma_pool_fn *destroy_dma_pool;
|
|
|
|
nvm_dev_dma_alloc_fn *dev_dma_alloc;
|
|
|
|
nvm_dev_dma_free_fn *dev_dma_free;
|
|
|
|
|
|
|
|
unsigned int max_phys_sect;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
#ifdef CONFIG_NVM
|
|
|
|
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/dmapool.h>
|
2016-01-11 23:49:36 -07:00
|
|
|
#include <uapi/linux/lightnvm.h>
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
enum {
|
|
|
|
/* HW Responsibilities */
|
|
|
|
NVM_RSP_L2P = 1 << 0,
|
|
|
|
NVM_RSP_ECC = 1 << 1,
|
|
|
|
|
|
|
|
/* Physical Adressing Mode */
|
|
|
|
NVM_ADDRMODE_LINEAR = 0,
|
|
|
|
NVM_ADDRMODE_CHANNEL = 1,
|
|
|
|
|
|
|
|
/* Plane programming mode for LUN */
|
2016-02-19 05:56:58 -07:00
|
|
|
NVM_PLANE_SINGLE = 1,
|
|
|
|
NVM_PLANE_DOUBLE = 2,
|
|
|
|
NVM_PLANE_QUAD = 4,
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
/* Status codes */
|
|
|
|
NVM_RSP_SUCCESS = 0x0,
|
|
|
|
NVM_RSP_NOT_CHANGEABLE = 0x1,
|
|
|
|
NVM_RSP_ERR_FAILWRITE = 0x40ff,
|
|
|
|
NVM_RSP_ERR_EMPTYPAGE = 0x42ff,
|
2016-11-28 14:38:57 -07:00
|
|
|
NVM_RSP_ERR_FAILECC = 0x4281,
|
|
|
|
NVM_RSP_WARN_HIGHECC = 0x4700,
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
/* Device opcodes */
|
|
|
|
NVM_OP_HBREAD = 0x02,
|
|
|
|
NVM_OP_HBWRITE = 0x81,
|
|
|
|
NVM_OP_PWRITE = 0x91,
|
|
|
|
NVM_OP_PREAD = 0x92,
|
|
|
|
NVM_OP_ERASE = 0x90,
|
|
|
|
|
|
|
|
/* PPA Command Flags */
|
|
|
|
NVM_IO_SNGL_ACCESS = 0x0,
|
|
|
|
NVM_IO_DUAL_ACCESS = 0x1,
|
|
|
|
NVM_IO_QUAD_ACCESS = 0x2,
|
|
|
|
|
2015-12-06 03:25:47 -07:00
|
|
|
/* NAND Access Modes */
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
NVM_IO_SUSPEND = 0x80,
|
|
|
|
NVM_IO_SLC_MODE = 0x100,
|
|
|
|
NVM_IO_SCRAMBLE_DISABLE = 0x200,
|
2015-12-06 03:25:47 -07:00
|
|
|
|
|
|
|
/* Block Types */
|
|
|
|
NVM_BLK_T_FREE = 0x0,
|
|
|
|
NVM_BLK_T_BAD = 0x1,
|
2016-01-11 23:49:32 -07:00
|
|
|
NVM_BLK_T_GRWN_BAD = 0x2,
|
|
|
|
NVM_BLK_T_DEV = 0x4,
|
|
|
|
NVM_BLK_T_HOST = 0x8,
|
2016-01-11 23:49:34 -07:00
|
|
|
|
|
|
|
/* Memory capabilities */
|
|
|
|
NVM_ID_CAP_SLC = 0x1,
|
|
|
|
NVM_ID_CAP_CMD_SUSPEND = 0x2,
|
|
|
|
NVM_ID_CAP_SCRAMBLE = 0x4,
|
|
|
|
NVM_ID_CAP_ENCRYPT = 0x8,
|
2016-01-11 23:49:35 -07:00
|
|
|
|
|
|
|
/* Memory types */
|
|
|
|
NVM_ID_FMTYPE_SLC = 0,
|
|
|
|
NVM_ID_FMTYPE_MLC = 1,
|
2016-02-04 07:13:27 -07:00
|
|
|
|
|
|
|
/* Device capabilities */
|
|
|
|
NVM_ID_DCAP_BBLKMGMT = 0x1,
|
|
|
|
NVM_UD_DCAP_ECC = 0x2,
|
2016-01-11 23:49:35 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_id_lp_mlc {
|
|
|
|
u16 num_pairs;
|
|
|
|
u8 pairs[886];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_id_lp_tbl {
|
|
|
|
__u8 id[8];
|
|
|
|
struct nvm_id_lp_mlc mlc;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_id_group {
|
|
|
|
u8 mtype;
|
|
|
|
u8 fmtype;
|
|
|
|
u8 num_ch;
|
|
|
|
u8 num_lun;
|
|
|
|
u8 num_pln;
|
|
|
|
u16 num_blk;
|
|
|
|
u16 num_pg;
|
|
|
|
u16 fpg_sz;
|
|
|
|
u16 csecs;
|
|
|
|
u16 sos;
|
|
|
|
u32 trdt;
|
|
|
|
u32 trdm;
|
|
|
|
u32 tprt;
|
|
|
|
u32 tprm;
|
|
|
|
u32 tbet;
|
|
|
|
u32 tbem;
|
|
|
|
u32 mpos;
|
2015-11-16 07:34:39 -07:00
|
|
|
u32 mccap;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
u16 cpar;
|
2016-01-11 23:49:35 -07:00
|
|
|
|
|
|
|
struct nvm_id_lp_tbl lptbl;
|
2015-11-16 07:34:40 -07:00
|
|
|
};
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
struct nvm_addr_format {
|
|
|
|
u8 ch_offset;
|
|
|
|
u8 ch_len;
|
|
|
|
u8 lun_offset;
|
|
|
|
u8 lun_len;
|
|
|
|
u8 pln_offset;
|
|
|
|
u8 pln_len;
|
|
|
|
u8 blk_offset;
|
|
|
|
u8 blk_len;
|
|
|
|
u8 pg_offset;
|
|
|
|
u8 pg_len;
|
|
|
|
u8 sect_offset;
|
|
|
|
u8 sect_len;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_id {
|
|
|
|
u8 ver_id;
|
|
|
|
u8 vmnt;
|
|
|
|
u8 cgrps;
|
|
|
|
u32 cap;
|
|
|
|
u32 dom;
|
|
|
|
struct nvm_addr_format ppaf;
|
|
|
|
struct nvm_id_group groups[4];
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
struct nvm_target {
|
|
|
|
struct list_head list;
|
2016-11-28 14:39:06 -07:00
|
|
|
struct nvm_tgt_dev *dev;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct nvm_tgt_type *type;
|
|
|
|
struct gendisk *disk;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_tgt_instance {
|
|
|
|
struct nvm_tgt_type *tt;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define ADDR_EMPTY (~0ULL)
|
|
|
|
|
|
|
|
#define NVM_VERSION_MAJOR 1
|
|
|
|
#define NVM_VERSION_MINOR 0
|
|
|
|
#define NVM_VERSION_PATCH 0
|
|
|
|
|
2016-01-11 23:49:21 -07:00
|
|
|
struct nvm_rq;
|
2016-01-11 23:49:29 -07:00
|
|
|
typedef void (nvm_end_io_fn)(struct nvm_rq *);
|
2016-01-11 23:49:21 -07:00
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct nvm_rq {
|
|
|
|
struct nvm_tgt_instance *ins;
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
struct nvm_tgt_dev *dev;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
union {
|
|
|
|
struct ppa_addr ppa_addr;
|
|
|
|
dma_addr_t dma_ppa_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ppa_addr *ppa_list;
|
|
|
|
|
2016-05-06 12:03:12 -06:00
|
|
|
void *meta_list;
|
|
|
|
dma_addr_t dma_meta_list;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
2016-01-11 23:49:21 -07:00
|
|
|
struct completion *wait;
|
|
|
|
nvm_end_io_fn *end_io;
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
uint8_t opcode;
|
2016-05-06 12:03:20 -06:00
|
|
|
uint16_t nr_ppas;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
uint16_t flags;
|
2016-01-11 23:49:29 -07:00
|
|
|
|
2016-03-03 07:06:39 -07:00
|
|
|
u64 ppa_status; /* ppa media status */
|
2016-01-11 23:49:29 -07:00
|
|
|
int error;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct nvm_rq *nvm_rq_from_pdu(void *pdu)
|
|
|
|
{
|
|
|
|
return pdu - sizeof(struct nvm_rq);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *nvm_rq_to_pdu(struct nvm_rq *rqdata)
|
|
|
|
{
|
|
|
|
return rqdata + 1;
|
|
|
|
}
|
|
|
|
|
2016-01-11 23:49:33 -07:00
|
|
|
enum {
|
|
|
|
NVM_BLK_ST_FREE = 0x1, /* Free block */
|
2016-07-07 01:54:14 -06:00
|
|
|
NVM_BLK_ST_TGT = 0x2, /* Block in use by target */
|
2016-01-11 23:49:33 -07:00
|
|
|
NVM_BLK_ST_BAD = 0x8, /* Bad block */
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
};
|
|
|
|
|
2016-01-11 23:49:36 -07:00
|
|
|
/* system block cpu representation */
|
|
|
|
struct nvm_sb_info {
|
|
|
|
unsigned long seqnr;
|
|
|
|
unsigned long erase_cnt;
|
|
|
|
unsigned int version;
|
|
|
|
char mmtype[NVM_MMTYPE_LEN];
|
|
|
|
struct ppa_addr fs_ppa;
|
|
|
|
};
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
/* Device generic information */
|
|
|
|
struct nvm_geo {
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
int nr_chnls;
|
2016-11-28 14:39:06 -07:00
|
|
|
int nr_luns;
|
|
|
|
int luns_per_chnl; /* -1 if channels are not symmetric */
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
int nr_planes;
|
|
|
|
int sec_per_pg; /* only sectors for a single page */
|
|
|
|
int pgs_per_blk;
|
|
|
|
int blks_per_lun;
|
2016-05-06 12:02:57 -06:00
|
|
|
int fpg_size;
|
|
|
|
int pfpg_size; /* size of buffer if all pages are to be read */
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
int sec_size;
|
|
|
|
int oob_size;
|
2016-01-11 23:49:34 -07:00
|
|
|
int mccap;
|
2015-11-16 07:34:44 -07:00
|
|
|
struct nvm_addr_format ppaf;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
/* Calculated/Cached values. These do not reflect the actual usable
|
|
|
|
* blocks at run-time.
|
|
|
|
*/
|
|
|
|
int max_rq_size;
|
|
|
|
int plane_mode; /* drive device in single, double or quad mode */
|
|
|
|
|
|
|
|
int sec_per_pl; /* all sectors across planes */
|
|
|
|
int sec_per_blk;
|
|
|
|
int sec_per_lun;
|
2016-11-28 14:39:06 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_tgt_dev {
|
|
|
|
/* Device information */
|
|
|
|
struct nvm_geo geo;
|
|
|
|
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
/* Base ppas for target LUNs */
|
|
|
|
struct ppa_addr *luns;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
sector_t total_secs;
|
|
|
|
|
|
|
|
struct nvm_id identity;
|
|
|
|
struct request_queue *q;
|
|
|
|
|
2016-11-28 14:39:11 -07:00
|
|
|
struct nvm_dev *parent;
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
void *map;
|
2016-11-28 14:39:06 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct nvm_dev {
|
|
|
|
struct nvm_dev_ops *ops;
|
|
|
|
|
|
|
|
struct list_head devices;
|
|
|
|
|
|
|
|
/* Media manager */
|
|
|
|
struct nvmm_type *mt;
|
|
|
|
void *mp;
|
|
|
|
|
|
|
|
/* System blocks */
|
|
|
|
struct nvm_sb_info sb;
|
|
|
|
|
|
|
|
/* Device information */
|
|
|
|
struct nvm_geo geo;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
2016-01-11 23:49:35 -07:00
|
|
|
/* lower page table */
|
|
|
|
int lps_per_blk;
|
|
|
|
int *lptbl;
|
|
|
|
|
2016-02-20 00:52:41 -07:00
|
|
|
unsigned long total_secs;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
2016-03-03 07:06:38 -07:00
|
|
|
unsigned long *lun_map;
|
2016-05-06 12:03:13 -06:00
|
|
|
void *dma_pool;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
struct nvm_id identity;
|
|
|
|
|
|
|
|
/* Backend device */
|
|
|
|
struct request_queue *q;
|
|
|
|
char name[DISK_NAME_LEN];
|
2016-09-16 06:25:08 -06:00
|
|
|
void *private_data;
|
2016-01-11 23:49:36 -07:00
|
|
|
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
void *rmap;
|
|
|
|
|
2016-01-11 23:49:36 -07:00
|
|
|
struct mutex mlock;
|
2016-03-03 07:06:37 -07:00
|
|
|
spinlock_t lock;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
};
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
static inline struct ppa_addr linear_to_generic_addr(struct nvm_geo *geo,
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
u64 pba)
|
2016-11-28 14:39:01 -07:00
|
|
|
{
|
|
|
|
struct ppa_addr l;
|
|
|
|
int secs, pgs, blks, luns;
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
sector_t ppa = pba;
|
2016-11-28 14:39:01 -07:00
|
|
|
|
|
|
|
l.ppa = 0;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
div_u64_rem(ppa, geo->sec_per_pg, &secs);
|
2016-11-28 14:39:01 -07:00
|
|
|
l.g.sec = secs;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
sector_div(ppa, geo->sec_per_pg);
|
|
|
|
div_u64_rem(ppa, geo->pgs_per_blk, &pgs);
|
2016-11-28 14:39:01 -07:00
|
|
|
l.g.pg = pgs;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
sector_div(ppa, geo->pgs_per_blk);
|
|
|
|
div_u64_rem(ppa, geo->blks_per_lun, &blks);
|
2016-11-28 14:39:01 -07:00
|
|
|
l.g.blk = blks;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
sector_div(ppa, geo->blks_per_lun);
|
|
|
|
div_u64_rem(ppa, geo->luns_per_chnl, &luns);
|
2016-11-28 14:39:01 -07:00
|
|
|
l.g.lun = luns;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
sector_div(ppa, geo->luns_per_chnl);
|
2016-11-28 14:39:01 -07:00
|
|
|
l.g.ch = ppa;
|
|
|
|
|
|
|
|
return l;
|
|
|
|
}
|
|
|
|
|
2015-11-16 07:34:44 -07:00
|
|
|
static inline struct ppa_addr generic_to_dev_addr(struct nvm_dev *dev,
|
|
|
|
struct ppa_addr r)
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
{
|
2016-11-28 14:39:06 -07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct ppa_addr l;
|
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
l.ppa = ((u64)r.g.blk) << geo->ppaf.blk_offset;
|
|
|
|
l.ppa |= ((u64)r.g.pg) << geo->ppaf.pg_offset;
|
|
|
|
l.ppa |= ((u64)r.g.sec) << geo->ppaf.sect_offset;
|
|
|
|
l.ppa |= ((u64)r.g.pl) << geo->ppaf.pln_offset;
|
|
|
|
l.ppa |= ((u64)r.g.lun) << geo->ppaf.lun_offset;
|
|
|
|
l.ppa |= ((u64)r.g.ch) << geo->ppaf.ch_offset;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
return l;
|
|
|
|
}
|
|
|
|
|
2015-11-16 07:34:44 -07:00
|
|
|
static inline struct ppa_addr dev_to_generic_addr(struct nvm_dev *dev,
|
|
|
|
struct ppa_addr r)
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
{
|
2016-11-28 14:39:06 -07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct ppa_addr l;
|
|
|
|
|
2016-07-07 01:54:09 -06:00
|
|
|
l.ppa = 0;
|
2015-11-16 07:34:44 -07:00
|
|
|
/*
|
|
|
|
* (r.ppa << X offset) & X len bitmask. X eq. blk, pg, etc.
|
|
|
|
*/
|
2016-11-28 14:39:06 -07:00
|
|
|
l.g.blk = (r.ppa >> geo->ppaf.blk_offset) &
|
|
|
|
(((1 << geo->ppaf.blk_len) - 1));
|
|
|
|
l.g.pg |= (r.ppa >> geo->ppaf.pg_offset) &
|
|
|
|
(((1 << geo->ppaf.pg_len) - 1));
|
|
|
|
l.g.sec |= (r.ppa >> geo->ppaf.sect_offset) &
|
|
|
|
(((1 << geo->ppaf.sect_len) - 1));
|
|
|
|
l.g.pl |= (r.ppa >> geo->ppaf.pln_offset) &
|
|
|
|
(((1 << geo->ppaf.pln_len) - 1));
|
|
|
|
l.g.lun |= (r.ppa >> geo->ppaf.lun_offset) &
|
|
|
|
(((1 << geo->ppaf.lun_len) - 1));
|
|
|
|
l.g.ch |= (r.ppa >> geo->ppaf.ch_offset) &
|
|
|
|
(((1 << geo->ppaf.ch_len) - 1));
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
return l;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int ppa_empty(struct ppa_addr ppa_addr)
|
|
|
|
{
|
|
|
|
return (ppa_addr.ppa == ADDR_EMPTY);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void ppa_set_empty(struct ppa_addr *ppa_addr)
|
|
|
|
{
|
|
|
|
ppa_addr->ppa = ADDR_EMPTY;
|
|
|
|
}
|
|
|
|
|
2016-11-28 14:38:56 -07:00
|
|
|
static inline int ppa_cmp_blk(struct ppa_addr ppa1, struct ppa_addr ppa2)
|
|
|
|
{
|
|
|
|
if (ppa_empty(ppa1) || ppa_empty(ppa2))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return ((ppa1.g.ch == ppa2.g.ch) && (ppa1.g.lun == ppa2.g.lun) &&
|
|
|
|
(ppa1.g.blk == ppa2.g.blk));
|
|
|
|
}
|
|
|
|
|
2016-01-11 23:49:36 -07:00
|
|
|
static inline int ppa_to_slc(struct nvm_dev *dev, int slc_pg)
|
|
|
|
{
|
|
|
|
return dev->lptbl[slc_pg];
|
|
|
|
}
|
|
|
|
|
2015-11-05 10:41:16 -07:00
|
|
|
typedef blk_qc_t (nvm_tgt_make_rq_fn)(struct request_queue *, struct bio *);
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
typedef sector_t (nvm_tgt_capacity_fn)(void *);
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
typedef void *(nvm_tgt_init_fn)(struct nvm_tgt_dev *, struct gendisk *);
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
typedef void (nvm_tgt_exit_fn)(void *);
|
|
|
|
|
|
|
|
struct nvm_tgt_type {
|
|
|
|
const char *name;
|
|
|
|
unsigned int version[3];
|
|
|
|
|
|
|
|
/* target entry points */
|
|
|
|
nvm_tgt_make_rq_fn *make_rq;
|
|
|
|
nvm_tgt_capacity_fn *capacity;
|
2016-01-11 23:49:21 -07:00
|
|
|
nvm_end_io_fn *end_io;
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
/* module-specific init/teardown */
|
|
|
|
nvm_tgt_init_fn *init;
|
|
|
|
nvm_tgt_exit_fn *exit;
|
|
|
|
|
|
|
|
/* For internal use */
|
|
|
|
struct list_head list;
|
|
|
|
};
|
|
|
|
|
2016-07-07 01:54:16 -06:00
|
|
|
extern struct nvm_tgt_type *nvm_find_target_type(const char *, int);
|
|
|
|
|
2016-05-06 12:03:02 -06:00
|
|
|
extern int nvm_register_tgt_type(struct nvm_tgt_type *);
|
|
|
|
extern void nvm_unregister_tgt_type(struct nvm_tgt_type *);
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
|
|
|
extern void *nvm_dev_dma_alloc(struct nvm_dev *, gfp_t, dma_addr_t *);
|
|
|
|
extern void nvm_dev_dma_free(struct nvm_dev *, void *, dma_addr_t);
|
|
|
|
|
|
|
|
typedef int (nvmm_register_fn)(struct nvm_dev *);
|
|
|
|
typedef void (nvmm_unregister_fn)(struct nvm_dev *);
|
2016-07-07 01:54:16 -06:00
|
|
|
|
|
|
|
typedef int (nvmm_create_tgt_fn)(struct nvm_dev *, struct nvm_ioctl_create *);
|
|
|
|
typedef int (nvmm_remove_tgt_fn)(struct nvm_dev *, struct nvm_ioctl_remove *);
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
typedef int (nvmm_submit_io_fn)(struct nvm_tgt_dev *, struct nvm_rq *);
|
|
|
|
typedef int (nvmm_erase_blk_fn)(struct nvm_tgt_dev *, struct ppa_addr *, int);
|
2016-03-03 07:06:37 -07:00
|
|
|
typedef int (nvmm_get_area_fn)(struct nvm_dev *, sector_t *, sector_t);
|
|
|
|
typedef void (nvmm_put_area_fn)(struct nvm_dev *, sector_t);
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
typedef void (nvmm_part_to_tgt_fn)(struct nvm_dev *, sector_t*, int);
|
2016-03-03 07:06:37 -07:00
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct nvmm_type {
|
|
|
|
const char *name;
|
|
|
|
unsigned int version[3];
|
|
|
|
|
|
|
|
nvmm_register_fn *register_mgr;
|
|
|
|
nvmm_unregister_fn *unregister_mgr;
|
|
|
|
|
2016-07-07 01:54:16 -06:00
|
|
|
nvmm_create_tgt_fn *create_tgt;
|
|
|
|
nvmm_remove_tgt_fn *remove_tgt;
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
nvmm_submit_io_fn *submit_io;
|
|
|
|
nvmm_erase_blk_fn *erase_blk;
|
|
|
|
|
2016-03-03 07:06:37 -07:00
|
|
|
nvmm_get_area_fn *get_area;
|
|
|
|
nvmm_put_area_fn *put_area;
|
|
|
|
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
nvmm_part_to_tgt_fn *part_to_tgt;
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
struct list_head list;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern int nvm_register_mgr(struct nvmm_type *);
|
|
|
|
extern void nvm_unregister_mgr(struct nvmm_type *);
|
|
|
|
|
2016-09-16 06:25:07 -06:00
|
|
|
extern struct nvm_dev *nvm_alloc_dev(int);
|
|
|
|
extern int nvm_register(struct nvm_dev *);
|
|
|
|
extern void nvm_unregister(struct nvm_dev *);
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
|
2016-11-28 14:38:56 -07:00
|
|
|
extern int nvm_set_bb_tbl(struct nvm_dev *dev, struct ppa_addr *ppas,
|
|
|
|
int nr_ppas, int type);
|
2016-07-07 01:54:08 -06:00
|
|
|
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
extern int nvm_submit_io(struct nvm_tgt_dev *, struct nvm_rq *);
|
2016-01-11 23:49:19 -07:00
|
|
|
extern void nvm_generic_to_addr_mode(struct nvm_dev *, struct nvm_rq *);
|
|
|
|
extern void nvm_addr_to_generic_mode(struct nvm_dev *, struct nvm_rq *);
|
2016-01-11 23:49:20 -07:00
|
|
|
extern int nvm_set_rqd_ppalist(struct nvm_dev *, struct nvm_rq *,
|
2016-07-07 01:54:22 -06:00
|
|
|
const struct ppa_addr *, int, int);
|
2016-01-11 23:49:20 -07:00
|
|
|
extern void nvm_free_rqd_ppalist(struct nvm_dev *, struct nvm_rq *);
|
2016-11-28 14:38:54 -07:00
|
|
|
extern int nvm_erase_ppa(struct nvm_dev *, struct ppa_addr *, int, int);
|
lightnvm: eliminate nvm_lun abstraction in mm
In order to naturally support multi-target instances on an Open-Channel
SSD, targets should own the LUNs they get blocks from and manage
provisioning internally. This is done in several steps.
Since targets own the LUNs the are instantiated on top of and manage the
free block list internally, there is no need for a LUN abstraction in
the media manager. LUNs are intrinsically managed as in the physical
layout (ch:0,lun:0, ..., ch:0,lun:n, ch:1,lun:0, ch:1,lun:n, ...,
ch:m,lun:0, ch:m,lun:n) and given to the targets based on the target
creation ioctl. This simplifies LUN management and clears the path for a
partition manager to sit directly underneath LightNVM targets.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-11-28 14:39:10 -07:00
|
|
|
extern int nvm_erase_blk(struct nvm_tgt_dev *, struct ppa_addr *, int);
|
|
|
|
extern int nvm_get_l2p_tbl(struct nvm_dev *, u64, u32, nvm_l2p_update_fn *,
|
|
|
|
void *);
|
|
|
|
extern int nvm_get_area(struct nvm_dev *, sector_t *, sector_t);
|
|
|
|
extern void nvm_put_area(struct nvm_dev *, sector_t);
|
2016-01-11 23:49:21 -07:00
|
|
|
extern void nvm_end_io(struct nvm_rq *, int);
|
2016-01-11 23:49:30 -07:00
|
|
|
extern int nvm_submit_ppa(struct nvm_dev *, struct ppa_addr *, int, int, int,
|
|
|
|
void *, int);
|
2016-05-06 12:02:56 -06:00
|
|
|
extern int nvm_submit_ppa_list(struct nvm_dev *, struct ppa_addr *, int, int,
|
|
|
|
int, void *, int);
|
2016-05-06 12:02:58 -06:00
|
|
|
extern int nvm_bb_tbl_fold(struct nvm_dev *, u8 *, int);
|
2016-05-06 12:03:05 -06:00
|
|
|
extern int nvm_get_bb_tbl(struct nvm_dev *, struct ppa_addr, u8 *);
|
2016-01-11 23:49:36 -07:00
|
|
|
|
|
|
|
/* sysblk.c */
|
|
|
|
#define NVM_SYSBLK_MAGIC 0x4E564D53 /* "NVMS" */
|
|
|
|
|
|
|
|
/* system block on disk representation */
|
|
|
|
struct nvm_system_block {
|
|
|
|
__be32 magic; /* magic signature */
|
|
|
|
__be32 seqnr; /* sequence number */
|
|
|
|
__be32 erase_cnt; /* erase count */
|
|
|
|
__be16 version; /* version number */
|
|
|
|
u8 mmtype[NVM_MMTYPE_LEN]; /* media manager name */
|
|
|
|
__be64 fs_ppa; /* PPA for media manager
|
|
|
|
* superblock */
|
|
|
|
};
|
|
|
|
|
|
|
|
extern int nvm_get_sysblock(struct nvm_dev *, struct nvm_sb_info *);
|
|
|
|
extern int nvm_update_sysblock(struct nvm_dev *, struct nvm_sb_info *);
|
|
|
|
extern int nvm_init_sysblock(struct nvm_dev *, struct nvm_sb_info *);
|
2016-01-11 23:49:39 -07:00
|
|
|
|
|
|
|
extern int nvm_dev_factory(struct nvm_dev *, int flags);
|
2016-05-06 12:03:04 -06:00
|
|
|
|
2016-11-28 14:39:06 -07:00
|
|
|
#define nvm_for_each_lun_ppa(geo, ppa, chid, lunid) \
|
|
|
|
for ((chid) = 0, (ppa).ppa = 0; (chid) < (geo)->nr_chnls; \
|
2016-05-06 12:03:04 -06:00
|
|
|
(chid)++, (ppa).g.ch = (chid)) \
|
2016-11-28 14:39:06 -07:00
|
|
|
for ((lunid) = 0; (lunid) < (geo)->luns_per_chnl; \
|
2016-05-06 12:03:04 -06:00
|
|
|
(lunid)++, (ppa).g.lun = (lunid))
|
|
|
|
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
#else /* CONFIG_NVM */
|
|
|
|
struct nvm_dev_ops;
|
|
|
|
|
2016-09-16 06:25:07 -06:00
|
|
|
static inline struct nvm_dev *nvm_alloc_dev(int node)
|
|
|
|
{
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
static inline int nvm_register(struct nvm_dev *dev)
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-09-16 06:25:07 -06:00
|
|
|
static inline void nvm_unregister(struct nvm_dev *dev) {}
|
lightnvm: Support for Open-Channel SSDs
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: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-10-28 12:54:55 -06:00
|
|
|
#endif /* CONFIG_NVM */
|
|
|
|
#endif /* LIGHTNVM.H */
|