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-29 01:54:55 +07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2015 IT University of Copenhagen. All rights reserved.
|
|
|
|
* Initial release: Matias Bjorling <m@bjorling.me>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License version
|
|
|
|
* 2 as published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; see the file COPYING. If not, write to
|
|
|
|
* the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
|
|
|
|
* USA.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/sem.h>
|
|
|
|
#include <linux/bitmap.h>
|
2016-10-30 03:38:41 +07:00
|
|
|
#include <linux/moduleparam.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-29 01:54:55 +07:00
|
|
|
#include <linux/miscdevice.h>
|
|
|
|
#include <linux/lightnvm.h>
|
2016-01-12 13:49:21 +07:00
|
|
|
#include <linux/sched/sysctl.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-29 01:54:55 +07:00
|
|
|
|
2016-05-07 01:03:02 +07:00
|
|
|
static LIST_HEAD(nvm_tgt_types);
|
2016-07-07 14:54:17 +07:00
|
|
|
static DECLARE_RWSEM(nvm_tgtt_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-29 01:54:55 +07:00
|
|
|
static LIST_HEAD(nvm_mgrs);
|
|
|
|
static LIST_HEAD(nvm_devices);
|
|
|
|
static DECLARE_RWSEM(nvm_lock);
|
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
struct nvm_tgt_type *nvm_find_target_type(const char *name, int lock)
|
2016-05-07 01:03:03 +07:00
|
|
|
{
|
2016-07-07 14:54:16 +07:00
|
|
|
struct nvm_tgt_type *tmp, *tt = NULL;
|
2016-05-07 01:03:03 +07:00
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
if (lock)
|
2016-07-07 14:54:17 +07:00
|
|
|
down_write(&nvm_tgtt_lock);
|
2016-05-07 01:03:03 +07:00
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
list_for_each_entry(tmp, &nvm_tgt_types, list)
|
|
|
|
if (!strcmp(name, tmp->name)) {
|
|
|
|
tt = tmp;
|
|
|
|
break;
|
|
|
|
}
|
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-29 01:54:55 +07:00
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
if (lock)
|
2016-07-07 14:54:17 +07:00
|
|
|
up_write(&nvm_tgtt_lock);
|
2016-07-07 14:54:16 +07:00
|
|
|
return tt;
|
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-29 01:54:55 +07:00
|
|
|
}
|
2016-07-07 14:54:16 +07:00
|
|
|
EXPORT_SYMBOL(nvm_find_target_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-29 01:54:55 +07:00
|
|
|
|
2016-05-07 01:03:02 +07:00
|
|
|
int nvm_register_tgt_type(struct nvm_tgt_type *tt)
|
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-29 01:54:55 +07:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2016-07-07 14:54:17 +07:00
|
|
|
down_write(&nvm_tgtt_lock);
|
2016-07-07 14:54:16 +07:00
|
|
|
if (nvm_find_target_type(tt->name, 0))
|
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-29 01:54:55 +07:00
|
|
|
ret = -EEXIST;
|
|
|
|
else
|
2016-05-07 01:03:02 +07:00
|
|
|
list_add(&tt->list, &nvm_tgt_types);
|
2016-07-07 14:54:17 +07:00
|
|
|
up_write(&nvm_tgtt_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-29 01:54:55 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2016-05-07 01:03:02 +07:00
|
|
|
EXPORT_SYMBOL(nvm_register_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-29 01:54:55 +07:00
|
|
|
|
2016-05-07 01:03:02 +07:00
|
|
|
void nvm_unregister_tgt_type(struct nvm_tgt_type *tt)
|
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-29 01:54:55 +07:00
|
|
|
{
|
|
|
|
if (!tt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
list_del(&tt->list);
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
}
|
2016-05-07 01:03:02 +07:00
|
|
|
EXPORT_SYMBOL(nvm_unregister_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-29 01:54:55 +07:00
|
|
|
|
|
|
|
void *nvm_dev_dma_alloc(struct nvm_dev *dev, gfp_t mem_flags,
|
|
|
|
dma_addr_t *dma_handler)
|
|
|
|
{
|
2016-05-07 01:03:13 +07:00
|
|
|
return dev->ops->dev_dma_alloc(dev, dev->dma_pool, mem_flags,
|
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-29 01:54:55 +07:00
|
|
|
dma_handler);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_dev_dma_alloc);
|
|
|
|
|
2016-11-29 04:39:13 +07:00
|
|
|
void nvm_dev_dma_free(struct nvm_dev *dev, void *addr, dma_addr_t dma_handler)
|
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-29 01:54:55 +07:00
|
|
|
{
|
2016-05-07 01:03:13 +07:00
|
|
|
dev->ops->dev_dma_free(dev->dma_pool, addr, dma_handler);
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_dev_dma_free);
|
|
|
|
|
|
|
|
static struct nvmm_type *nvm_find_mgr_type(const char *name)
|
|
|
|
{
|
|
|
|
struct nvmm_type *mt;
|
|
|
|
|
|
|
|
list_for_each_entry(mt, &nvm_mgrs, list)
|
|
|
|
if (!strcmp(name, mt->name))
|
|
|
|
return mt;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-07-07 14:54:11 +07:00
|
|
|
static struct nvmm_type *nvm_init_mgr(struct nvm_dev *dev)
|
2015-12-06 17:25:49 +07:00
|
|
|
{
|
|
|
|
struct nvmm_type *mt;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
lockdep_assert_held(&nvm_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(mt, &nvm_mgrs, list) {
|
2016-01-12 13:49:38 +07:00
|
|
|
if (strncmp(dev->sb.mmtype, mt->name, NVM_MMTYPE_LEN))
|
|
|
|
continue;
|
|
|
|
|
2015-12-06 17:25:49 +07:00
|
|
|
ret = mt->register_mgr(dev);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("nvm: media mgr failed to init (%d) on dev %s\n",
|
|
|
|
ret, dev->name);
|
|
|
|
return NULL; /* initialization failed */
|
|
|
|
} else if (ret > 0)
|
|
|
|
return mt;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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-29 01:54:55 +07:00
|
|
|
int nvm_register_mgr(struct nvmm_type *mt)
|
|
|
|
{
|
2015-12-06 17:25:49 +07:00
|
|
|
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-29 01:54:55 +07:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
2015-12-06 17:25:49 +07:00
|
|
|
if (nvm_find_mgr_type(mt->name)) {
|
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-29 01:54:55 +07:00
|
|
|
ret = -EEXIST;
|
2015-12-06 17:25:49 +07:00
|
|
|
goto finish;
|
|
|
|
} else {
|
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-29 01:54:55 +07:00
|
|
|
list_add(&mt->list, &nvm_mgrs);
|
2015-12-06 17:25:49 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* try to register media mgr if any device have none configured */
|
|
|
|
list_for_each_entry(dev, &nvm_devices, devices) {
|
|
|
|
if (dev->mt)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
dev->mt = nvm_init_mgr(dev);
|
|
|
|
}
|
|
|
|
finish:
|
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-29 01:54:55 +07:00
|
|
|
up_write(&nvm_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_register_mgr);
|
|
|
|
|
|
|
|
void nvm_unregister_mgr(struct nvmm_type *mt)
|
|
|
|
{
|
|
|
|
if (!mt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
list_del(&mt->list);
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_unregister_mgr);
|
|
|
|
|
|
|
|
static struct nvm_dev *nvm_find_nvm_dev(const char *name)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &nvm_devices, devices)
|
|
|
|
if (!strcmp(name, dev->name))
|
|
|
|
return dev;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-11-29 04:39:14 +07:00
|
|
|
static void nvm_tgt_generic_to_addr_mode(struct nvm_tgt_dev *tgt_dev,
|
|
|
|
struct nvm_rq *rqd)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (rqd->nr_ppas > 1) {
|
|
|
|
for (i = 0; i < rqd->nr_ppas; i++) {
|
|
|
|
rqd->ppa_list[i] = dev->mt->trans_ppa(tgt_dev,
|
|
|
|
rqd->ppa_list[i], TRANS_TGT_TO_DEV);
|
|
|
|
rqd->ppa_list[i] = generic_to_dev_addr(dev,
|
|
|
|
rqd->ppa_list[i]);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
rqd->ppa_addr = dev->mt->trans_ppa(tgt_dev, rqd->ppa_addr,
|
|
|
|
TRANS_TGT_TO_DEV);
|
|
|
|
rqd->ppa_addr = generic_to_dev_addr(dev, rqd->ppa_addr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-29 04:38:56 +07:00
|
|
|
int nvm_set_bb_tbl(struct nvm_dev *dev, struct ppa_addr *ppas, int nr_ppas,
|
|
|
|
int type)
|
|
|
|
{
|
|
|
|
struct nvm_rq rqd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (nr_ppas > dev->ops->max_phys_sect) {
|
|
|
|
pr_err("nvm: unable to update all sysblocks atomically\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&rqd, 0, sizeof(struct nvm_rq));
|
|
|
|
|
|
|
|
nvm_set_rqd_ppalist(dev, &rqd, ppas, nr_ppas, 1);
|
|
|
|
nvm_generic_to_addr_mode(dev, &rqd);
|
|
|
|
|
|
|
|
ret = dev->ops->set_bb_tbl(dev, &rqd.ppa_addr, rqd.nr_ppas, type);
|
|
|
|
nvm_free_rqd_ppalist(dev, &rqd);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("nvm: sysblk failed bb mark\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_set_bb_tbl);
|
|
|
|
|
2016-11-29 04:39:14 +07:00
|
|
|
int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
|
|
|
|
int nr_ppas, int type)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
struct nvm_rq rqd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (nr_ppas > dev->ops->max_phys_sect) {
|
|
|
|
pr_err("nvm: unable to update all blocks atomically\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&rqd, 0, sizeof(struct nvm_rq));
|
|
|
|
|
|
|
|
nvm_set_rqd_ppalist(dev, &rqd, ppas, nr_ppas, 1);
|
|
|
|
nvm_tgt_generic_to_addr_mode(tgt_dev, &rqd);
|
|
|
|
|
|
|
|
ret = dev->ops->set_bb_tbl(dev, &rqd.ppa_addr, rqd.nr_ppas, type);
|
|
|
|
nvm_free_rqd_ppalist(dev, &rqd);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("nvm: sysblk failed bb mark\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_set_tgt_bb_tbl);
|
|
|
|
|
2016-11-29 04:39:12 +07:00
|
|
|
int nvm_max_phys_sects(struct nvm_tgt_dev *tgt_dev)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
|
|
|
return dev->ops->max_phys_sect;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_max_phys_sects);
|
|
|
|
|
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-29 04:39:10 +07:00
|
|
|
int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
|
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-29 01:54:55 +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-29 04:39:10 +07:00
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
|
|
|
return dev->mt->submit_io(tgt_dev, rqd);
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_submit_io);
|
|
|
|
|
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-29 04:39:10 +07:00
|
|
|
int nvm_erase_blk(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *p, int flags)
|
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-29 01:54:55 +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-29 04:39:10 +07:00
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
|
|
|
return dev->mt->erase_blk(tgt_dev, p, flags);
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_erase_blk);
|
|
|
|
|
2016-11-29 04:39:13 +07:00
|
|
|
int nvm_get_l2p_tbl(struct nvm_tgt_dev *tgt_dev, u64 slba, u32 nlb,
|
2016-11-29 04:39:11 +07:00
|
|
|
nvm_l2p_update_fn *update_l2p, void *priv)
|
|
|
|
{
|
2016-11-29 04:39:13 +07:00
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
2016-11-29 04:39:11 +07:00
|
|
|
if (!dev->ops->get_l2p_tbl)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return dev->ops->get_l2p_tbl(dev, slba, nlb, update_l2p, priv);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_get_l2p_tbl);
|
|
|
|
|
2016-11-29 04:39:13 +07:00
|
|
|
int nvm_get_area(struct nvm_tgt_dev *tgt_dev, sector_t *lba, sector_t len)
|
2016-11-29 04:39:11 +07:00
|
|
|
{
|
2016-11-29 04:39:13 +07:00
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
2016-11-29 04:39:11 +07:00
|
|
|
return dev->mt->get_area(dev, lba, len);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_get_area);
|
|
|
|
|
2016-11-29 04:39:13 +07:00
|
|
|
void nvm_put_area(struct nvm_tgt_dev *tgt_dev, sector_t lba)
|
2016-11-29 04:39:11 +07:00
|
|
|
{
|
2016-11-29 04:39:13 +07:00
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
2016-11-29 04:39:11 +07:00
|
|
|
dev->mt->put_area(dev, lba);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_put_area);
|
|
|
|
|
2016-01-12 13:49:19 +07:00
|
|
|
void nvm_addr_to_generic_mode(struct nvm_dev *dev, struct nvm_rq *rqd)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2016-05-07 01:03:20 +07:00
|
|
|
if (rqd->nr_ppas > 1) {
|
|
|
|
for (i = 0; i < rqd->nr_ppas; i++)
|
2016-01-12 13:49:19 +07:00
|
|
|
rqd->ppa_list[i] = dev_to_generic_addr(dev,
|
|
|
|
rqd->ppa_list[i]);
|
|
|
|
} else {
|
|
|
|
rqd->ppa_addr = dev_to_generic_addr(dev, rqd->ppa_addr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_addr_to_generic_mode);
|
|
|
|
|
|
|
|
void nvm_generic_to_addr_mode(struct nvm_dev *dev, struct nvm_rq *rqd)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2016-05-07 01:03:20 +07:00
|
|
|
if (rqd->nr_ppas > 1) {
|
|
|
|
for (i = 0; i < rqd->nr_ppas; i++)
|
2016-01-12 13:49:19 +07:00
|
|
|
rqd->ppa_list[i] = generic_to_dev_addr(dev,
|
|
|
|
rqd->ppa_list[i]);
|
|
|
|
} else {
|
|
|
|
rqd->ppa_addr = generic_to_dev_addr(dev, rqd->ppa_addr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_generic_to_addr_mode);
|
|
|
|
|
2016-01-12 13:49:20 +07:00
|
|
|
int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
|
2016-07-07 14:54:22 +07:00
|
|
|
const struct ppa_addr *ppas, int nr_ppas, int vblk)
|
2016-01-12 13:49:19 +07:00
|
|
|
{
|
2016-11-29 04:39:06 +07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
2016-01-12 13:49:20 +07:00
|
|
|
int i, plane_cnt, pl_idx;
|
2016-07-07 14:54:22 +07:00
|
|
|
struct ppa_addr ppa;
|
2016-01-12 13:49:20 +07:00
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
if ((!vblk || geo->plane_mode == NVM_PLANE_SINGLE) && nr_ppas == 1) {
|
2016-05-07 01:03:20 +07:00
|
|
|
rqd->nr_ppas = nr_ppas;
|
2016-01-12 13:49:20 +07:00
|
|
|
rqd->ppa_addr = ppas[0];
|
2016-01-12 13:49:19 +07:00
|
|
|
|
|
|
|
return 0;
|
2016-01-12 13:49:20 +07:00
|
|
|
}
|
2016-01-12 13:49:19 +07:00
|
|
|
|
2016-05-07 01:03:20 +07:00
|
|
|
rqd->nr_ppas = nr_ppas;
|
2016-01-12 13:49:20 +07:00
|
|
|
rqd->ppa_list = nvm_dev_dma_alloc(dev, GFP_KERNEL, &rqd->dma_ppa_list);
|
|
|
|
if (!rqd->ppa_list) {
|
|
|
|
pr_err("nvm: failed to allocate dma memory\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2016-05-07 01:03:07 +07:00
|
|
|
if (!vblk) {
|
|
|
|
for (i = 0; i < nr_ppas; i++)
|
|
|
|
rqd->ppa_list[i] = ppas[i];
|
|
|
|
} else {
|
2016-11-29 04:39:06 +07:00
|
|
|
plane_cnt = geo->plane_mode;
|
2016-05-07 01:03:20 +07:00
|
|
|
rqd->nr_ppas *= plane_cnt;
|
2016-05-07 01:03:07 +07:00
|
|
|
|
2016-01-12 13:49:26 +07:00
|
|
|
for (i = 0; i < nr_ppas; i++) {
|
2016-05-07 01:03:07 +07:00
|
|
|
for (pl_idx = 0; pl_idx < plane_cnt; pl_idx++) {
|
2016-07-07 14:54:22 +07:00
|
|
|
ppa = ppas[i];
|
|
|
|
ppa.g.pl = pl_idx;
|
|
|
|
rqd->ppa_list[(pl_idx * nr_ppas) + i] = ppa;
|
2016-05-07 01:03:07 +07:00
|
|
|
}
|
2016-01-12 13:49:19 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-12 13:49:20 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_set_rqd_ppalist);
|
|
|
|
|
|
|
|
void nvm_free_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd)
|
|
|
|
{
|
|
|
|
if (!rqd->ppa_list)
|
|
|
|
return;
|
|
|
|
|
|
|
|
nvm_dev_dma_free(dev, rqd->ppa_list, rqd->dma_ppa_list);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_free_rqd_ppalist);
|
|
|
|
|
2016-11-29 04:38:54 +07:00
|
|
|
int nvm_erase_ppa(struct nvm_dev *dev, struct ppa_addr *ppas, int nr_ppas,
|
|
|
|
int flags)
|
2016-01-12 13:49:20 +07:00
|
|
|
{
|
|
|
|
struct nvm_rq rqd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!dev->ops->erase_block)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
memset(&rqd, 0, sizeof(struct nvm_rq));
|
|
|
|
|
2016-05-07 01:03:07 +07:00
|
|
|
ret = nvm_set_rqd_ppalist(dev, &rqd, ppas, nr_ppas, 1);
|
2016-01-12 13:49:20 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-01-12 13:49:19 +07:00
|
|
|
nvm_generic_to_addr_mode(dev, &rqd);
|
|
|
|
|
2016-11-29 04:38:54 +07:00
|
|
|
rqd.flags = flags;
|
|
|
|
|
2016-01-12 13:49:19 +07:00
|
|
|
ret = dev->ops->erase_block(dev, &rqd);
|
|
|
|
|
2016-01-12 13:49:20 +07:00
|
|
|
nvm_free_rqd_ppalist(dev, &rqd);
|
2016-01-12 13:49:19 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_erase_ppa);
|
|
|
|
|
2016-01-12 13:49:21 +07:00
|
|
|
void nvm_end_io(struct nvm_rq *rqd, int error)
|
|
|
|
{
|
2016-01-12 13:49:29 +07:00
|
|
|
rqd->error = error;
|
|
|
|
rqd->end_io(rqd);
|
2016-01-12 13:49:21 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_end_io);
|
|
|
|
|
2016-01-12 13:49:30 +07:00
|
|
|
static void nvm_end_io_sync(struct nvm_rq *rqd)
|
2016-01-12 13:49:21 +07:00
|
|
|
{
|
|
|
|
struct completion *waiting = rqd->wait;
|
|
|
|
|
|
|
|
rqd->wait = NULL;
|
|
|
|
|
|
|
|
complete(waiting);
|
|
|
|
}
|
|
|
|
|
2016-07-07 14:54:23 +07:00
|
|
|
static int __nvm_submit_ppa(struct nvm_dev *dev, struct nvm_rq *rqd, int opcode,
|
2016-05-07 01:02:56 +07:00
|
|
|
int flags, void *buf, int len)
|
2016-01-12 13:49:30 +07:00
|
|
|
{
|
|
|
|
DECLARE_COMPLETION_ONSTACK(wait);
|
|
|
|
struct bio *bio;
|
|
|
|
int ret;
|
|
|
|
unsigned long hang_check;
|
|
|
|
|
|
|
|
bio = bio_map_kern(dev->q, buf, len, GFP_KERNEL);
|
|
|
|
if (IS_ERR_OR_NULL(bio))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2016-05-07 01:02:56 +07:00
|
|
|
nvm_generic_to_addr_mode(dev, rqd);
|
2016-01-12 13:49:30 +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-29 04:39:10 +07:00
|
|
|
rqd->dev = NULL;
|
2016-05-07 01:02:56 +07:00
|
|
|
rqd->opcode = opcode;
|
|
|
|
rqd->flags = flags;
|
|
|
|
rqd->bio = bio;
|
|
|
|
rqd->wait = &wait;
|
|
|
|
rqd->end_io = nvm_end_io_sync;
|
2016-01-12 13:49:30 +07:00
|
|
|
|
2016-05-07 01:02:56 +07:00
|
|
|
ret = dev->ops->submit_io(dev, rqd);
|
2016-05-07 01:02:55 +07:00
|
|
|
if (ret) {
|
|
|
|
bio_put(bio);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-01-12 13:49:30 +07:00
|
|
|
|
|
|
|
/* Prevent hang_check timer from firing at us during very long I/O */
|
|
|
|
hang_check = sysctl_hung_task_timeout_secs;
|
|
|
|
if (hang_check)
|
2016-07-07 14:54:13 +07:00
|
|
|
while (!wait_for_completion_io_timeout(&wait,
|
|
|
|
hang_check * (HZ/2)))
|
|
|
|
;
|
2016-01-12 13:49:30 +07:00
|
|
|
else
|
|
|
|
wait_for_completion_io(&wait);
|
|
|
|
|
2016-05-07 01:02:56 +07:00
|
|
|
return rqd->error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* nvm_submit_ppa_list - submit user-defined ppa list to device. The user must
|
|
|
|
* take to free ppa list if necessary.
|
|
|
|
* @dev: device
|
|
|
|
* @ppa_list: user created ppa_list
|
|
|
|
* @nr_ppas: length of ppa_list
|
|
|
|
* @opcode: device opcode
|
|
|
|
* @flags: device flags
|
|
|
|
* @buf: data buffer
|
|
|
|
* @len: data buffer length
|
|
|
|
*/
|
|
|
|
int nvm_submit_ppa_list(struct nvm_dev *dev, struct ppa_addr *ppa_list,
|
|
|
|
int nr_ppas, int opcode, int flags, void *buf, int len)
|
|
|
|
{
|
|
|
|
struct nvm_rq rqd;
|
|
|
|
|
|
|
|
if (dev->ops->max_phys_sect < nr_ppas)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
memset(&rqd, 0, sizeof(struct nvm_rq));
|
|
|
|
|
2016-05-07 01:03:20 +07:00
|
|
|
rqd.nr_ppas = nr_ppas;
|
2016-05-07 01:02:56 +07:00
|
|
|
if (nr_ppas > 1)
|
|
|
|
rqd.ppa_list = ppa_list;
|
|
|
|
else
|
|
|
|
rqd.ppa_addr = ppa_list[0];
|
|
|
|
|
|
|
|
return __nvm_submit_ppa(dev, &rqd, opcode, flags, buf, len);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_submit_ppa_list);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* nvm_submit_ppa - submit PPAs to device. PPAs will automatically be unfolded
|
|
|
|
* as single, dual, quad plane PPAs depending on device type.
|
|
|
|
* @dev: device
|
|
|
|
* @ppa: user created ppa_list
|
|
|
|
* @nr_ppas: length of ppa_list
|
|
|
|
* @opcode: device opcode
|
|
|
|
* @flags: device flags
|
|
|
|
* @buf: data buffer
|
|
|
|
* @len: data buffer length
|
|
|
|
*/
|
|
|
|
int nvm_submit_ppa(struct nvm_dev *dev, struct ppa_addr *ppa, int nr_ppas,
|
|
|
|
int opcode, int flags, void *buf, int len)
|
|
|
|
{
|
|
|
|
struct nvm_rq rqd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(&rqd, 0, sizeof(struct nvm_rq));
|
2016-05-07 01:03:07 +07:00
|
|
|
ret = nvm_set_rqd_ppalist(dev, &rqd, ppa, nr_ppas, 1);
|
2016-05-07 01:02:56 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = __nvm_submit_ppa(dev, &rqd, opcode, flags, buf, len);
|
|
|
|
|
2016-01-12 13:49:30 +07:00
|
|
|
nvm_free_rqd_ppalist(dev, &rqd);
|
|
|
|
|
2016-05-07 01:02:56 +07:00
|
|
|
return ret;
|
2016-01-12 13:49:30 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_submit_ppa);
|
|
|
|
|
2016-05-07 01:02:58 +07:00
|
|
|
/*
|
|
|
|
* folds a bad block list from its plane representation to its virtual
|
|
|
|
* block representation. The fold is done in place and reduced size is
|
|
|
|
* returned.
|
|
|
|
*
|
|
|
|
* If any of the planes status are bad or grown bad block, the virtual block
|
|
|
|
* is marked bad. If not bad, the first plane state acts as the block state.
|
|
|
|
*/
|
|
|
|
int nvm_bb_tbl_fold(struct nvm_dev *dev, u8 *blks, int nr_blks)
|
|
|
|
{
|
2016-11-29 04:39:06 +07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
2016-05-07 01:02:58 +07:00
|
|
|
int blk, offset, pl, blktype;
|
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
if (nr_blks != geo->blks_per_lun * geo->plane_mode)
|
2016-05-07 01:02:58 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
for (blk = 0; blk < geo->blks_per_lun; blk++) {
|
|
|
|
offset = blk * geo->plane_mode;
|
2016-05-07 01:02:58 +07:00
|
|
|
blktype = blks[offset];
|
|
|
|
|
|
|
|
/* Bad blocks on any planes take precedence over other types */
|
2016-11-29 04:39:06 +07:00
|
|
|
for (pl = 0; pl < geo->plane_mode; pl++) {
|
2016-05-07 01:02:58 +07:00
|
|
|
if (blks[offset + pl] &
|
|
|
|
(NVM_BLK_T_BAD|NVM_BLK_T_GRWN_BAD)) {
|
|
|
|
blktype = blks[offset + pl];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
blks[blk] = blktype;
|
|
|
|
}
|
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
return geo->blks_per_lun;
|
2016-05-07 01:02:58 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_bb_tbl_fold);
|
|
|
|
|
2016-05-07 01:03:05 +07:00
|
|
|
int nvm_get_bb_tbl(struct nvm_dev *dev, struct ppa_addr ppa, u8 *blks)
|
|
|
|
{
|
|
|
|
ppa = generic_to_dev_addr(dev, ppa);
|
|
|
|
|
|
|
|
return dev->ops->get_bb_tbl(dev, ppa, blks);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_get_bb_tbl);
|
|
|
|
|
2016-11-29 04:39:14 +07:00
|
|
|
int nvm_get_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr ppa,
|
|
|
|
u8 *blks)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev = tgt_dev->parent;
|
|
|
|
|
|
|
|
ppa = dev->mt->trans_ppa(tgt_dev, ppa, TRANS_TGT_TO_DEV);
|
|
|
|
return nvm_get_bb_tbl(dev, ppa, blks);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_get_tgt_bb_tbl);
|
|
|
|
|
2016-01-12 13:49:35 +07:00
|
|
|
static int nvm_init_slc_tbl(struct nvm_dev *dev, struct nvm_id_group *grp)
|
|
|
|
{
|
2016-11-29 04:39:06 +07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
2016-01-12 13:49:35 +07:00
|
|
|
int i;
|
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
dev->lps_per_blk = geo->pgs_per_blk;
|
2016-01-12 13:49:35 +07:00
|
|
|
dev->lptbl = kcalloc(dev->lps_per_blk, sizeof(int), GFP_KERNEL);
|
|
|
|
if (!dev->lptbl)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Just a linear array */
|
|
|
|
for (i = 0; i < dev->lps_per_blk; i++)
|
|
|
|
dev->lptbl[i] = i;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int nvm_init_mlc_tbl(struct nvm_dev *dev, struct nvm_id_group *grp)
|
|
|
|
{
|
|
|
|
int i, p;
|
|
|
|
struct nvm_id_lp_mlc *mlc = &grp->lptbl.mlc;
|
|
|
|
|
|
|
|
if (!mlc->num_pairs)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dev->lps_per_blk = mlc->num_pairs;
|
|
|
|
dev->lptbl = kcalloc(dev->lps_per_blk, sizeof(int), GFP_KERNEL);
|
|
|
|
if (!dev->lptbl)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* The lower page table encoding consists of a list of bytes, where each
|
|
|
|
* has a lower and an upper half. The first half byte maintains the
|
|
|
|
* increment value and every value after is an offset added to the
|
2016-07-07 14:54:13 +07:00
|
|
|
* previous incrementation value
|
|
|
|
*/
|
2016-01-12 13:49:35 +07:00
|
|
|
dev->lptbl[0] = mlc->pairs[0] & 0xF;
|
|
|
|
for (i = 1; i < dev->lps_per_blk; i++) {
|
|
|
|
p = mlc->pairs[i >> 1];
|
|
|
|
if (i & 0x1) /* upper */
|
|
|
|
dev->lptbl[i] = dev->lptbl[i - 1] + ((p & 0xF0) >> 4);
|
|
|
|
else /* lower */
|
|
|
|
dev->lptbl[i] = dev->lptbl[i - 1] + (p & 0xF);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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-29 01:54:55 +07:00
|
|
|
static int nvm_core_init(struct nvm_dev *dev)
|
|
|
|
{
|
|
|
|
struct nvm_id *id = &dev->identity;
|
|
|
|
struct nvm_id_group *grp = &id->groups[0];
|
2016-11-29 04:39:06 +07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
2016-05-07 01:02:59 +07:00
|
|
|
int ret;
|
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-29 01:54:55 +07:00
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
/* Whole device values */
|
|
|
|
geo->nr_chnls = grp->num_ch;
|
|
|
|
geo->luns_per_chnl = grp->num_lun;
|
|
|
|
|
|
|
|
/* Generic device values */
|
|
|
|
geo->pgs_per_blk = grp->num_pg;
|
|
|
|
geo->blks_per_lun = grp->num_blk;
|
|
|
|
geo->nr_planes = grp->num_pln;
|
|
|
|
geo->fpg_size = grp->fpg_sz;
|
|
|
|
geo->pfpg_size = grp->fpg_sz * grp->num_pln;
|
|
|
|
geo->sec_size = grp->csecs;
|
|
|
|
geo->oob_size = grp->sos;
|
|
|
|
geo->sec_per_pg = grp->fpg_sz / grp->csecs;
|
|
|
|
geo->mccap = grp->mccap;
|
|
|
|
memcpy(&geo->ppaf, &id->ppaf, sizeof(struct nvm_addr_format));
|
|
|
|
|
|
|
|
geo->plane_mode = NVM_PLANE_SINGLE;
|
|
|
|
geo->max_rq_size = dev->ops->max_phys_sect * geo->sec_size;
|
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-29 01:54:55 +07:00
|
|
|
|
|
|
|
if (grp->mpos & 0x020202)
|
2016-11-29 04:39:06 +07:00
|
|
|
geo->plane_mode = NVM_PLANE_DOUBLE;
|
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-29 01:54:55 +07:00
|
|
|
if (grp->mpos & 0x040404)
|
2016-11-29 04:39:06 +07:00
|
|
|
geo->plane_mode = NVM_PLANE_QUAD;
|
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-29 01:54:55 +07:00
|
|
|
|
2016-05-07 01:02:59 +07:00
|
|
|
if (grp->mtype != 0) {
|
|
|
|
pr_err("nvm: memory type not supported\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
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-29 01:54:55 +07:00
|
|
|
/* calculated values */
|
2016-11-29 04:39:06 +07:00
|
|
|
geo->sec_per_pl = geo->sec_per_pg * geo->nr_planes;
|
|
|
|
geo->sec_per_blk = geo->sec_per_pl * geo->pgs_per_blk;
|
|
|
|
geo->sec_per_lun = geo->sec_per_blk * geo->blks_per_lun;
|
|
|
|
geo->nr_luns = geo->luns_per_chnl * geo->nr_chnls;
|
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-29 01:54:55 +07:00
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
dev->total_secs = geo->nr_luns * geo->sec_per_lun;
|
|
|
|
dev->lun_map = kcalloc(BITS_TO_LONGS(geo->nr_luns),
|
2016-03-03 21:06:38 +07:00
|
|
|
sizeof(unsigned long), GFP_KERNEL);
|
|
|
|
if (!dev->lun_map)
|
|
|
|
return -ENOMEM;
|
2016-05-07 01:02:59 +07:00
|
|
|
|
|
|
|
switch (grp->fmtype) {
|
|
|
|
case NVM_ID_FMTYPE_SLC:
|
|
|
|
if (nvm_init_slc_tbl(dev, grp)) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_fmtype;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case NVM_ID_FMTYPE_MLC:
|
|
|
|
if (nvm_init_mlc_tbl(dev, grp)) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_fmtype;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("nvm: flash type not supported\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_fmtype;
|
|
|
|
}
|
|
|
|
|
2016-01-12 13:49:36 +07:00
|
|
|
mutex_init(&dev->mlock);
|
2016-03-03 21:06:37 +07:00
|
|
|
spin_lock_init(&dev->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-29 01:54:55 +07:00
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
blk_queue_logical_block_size(dev->q, geo->sec_size);
|
2016-09-16 19:25:04 +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-29 01:54:55 +07:00
|
|
|
return 0;
|
2016-05-07 01:02:59 +07:00
|
|
|
err_fmtype:
|
|
|
|
kfree(dev->lun_map);
|
|
|
|
return ret;
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
|
2016-05-07 01:03:17 +07:00
|
|
|
static void nvm_free_mgr(struct nvm_dev *dev)
|
|
|
|
{
|
|
|
|
if (!dev->mt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dev->mt->unregister_mgr(dev);
|
|
|
|
dev->mt = NULL;
|
|
|
|
}
|
|
|
|
|
2016-09-16 19:25:08 +07:00
|
|
|
void nvm_free(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-29 01:54:55 +07:00
|
|
|
{
|
|
|
|
if (!dev)
|
|
|
|
return;
|
|
|
|
|
2016-05-07 01:03:17 +07:00
|
|
|
nvm_free_mgr(dev);
|
2016-01-12 13:49:35 +07:00
|
|
|
|
2016-09-16 19:25:08 +07:00
|
|
|
if (dev->dma_pool)
|
|
|
|
dev->ops->destroy_dma_pool(dev->dma_pool);
|
|
|
|
|
2016-01-12 13:49:35 +07:00
|
|
|
kfree(dev->lptbl);
|
2016-05-07 01:02:59 +07:00
|
|
|
kfree(dev->lun_map);
|
2016-09-16 19:25:08 +07:00
|
|
|
kfree(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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int nvm_init(struct nvm_dev *dev)
|
|
|
|
{
|
2016-11-29 04:39:06 +07:00
|
|
|
struct nvm_geo *geo = &dev->geo;
|
2015-11-20 19:47:53 +07:00
|
|
|
int ret = -EINVAL;
|
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-29 01:54:55 +07:00
|
|
|
|
|
|
|
if (!dev->q || !dev->ops)
|
2015-11-20 19:47:53 +07:00
|
|
|
return ret;
|
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-29 01:54:55 +07:00
|
|
|
|
2015-12-06 17:25:48 +07:00
|
|
|
if (dev->ops->identity(dev, &dev->identity)) {
|
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-29 01:54:55 +07:00
|
|
|
pr_err("nvm: device could not be identified\n");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("nvm: ver:%x nvm_vendor:%x groups:%u\n",
|
|
|
|
dev->identity.ver_id, dev->identity.vmnt,
|
|
|
|
dev->identity.cgrps);
|
|
|
|
|
|
|
|
if (dev->identity.ver_id != 1) {
|
|
|
|
pr_err("nvm: device not supported by kernel.");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dev->identity.cgrps != 1) {
|
|
|
|
pr_err("nvm: only one group configuration supported.");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = nvm_core_init(dev);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("nvm: could not initialize core structures.\n");
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_info("nvm: registered %s [%u/%u/%u/%u/%u/%u]\n",
|
2016-11-29 04:39:06 +07:00
|
|
|
dev->name, geo->sec_per_pg, geo->nr_planes,
|
|
|
|
geo->pgs_per_blk, geo->blks_per_lun,
|
|
|
|
geo->nr_luns, geo->nr_chnls);
|
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-29 01:54:55 +07:00
|
|
|
return 0;
|
|
|
|
err:
|
|
|
|
pr_err("nvm: failed to initialize nvm\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-09-16 19:25:07 +07:00
|
|
|
struct nvm_dev *nvm_alloc_dev(int node)
|
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-29 01:54:55 +07:00
|
|
|
{
|
2016-09-16 19:25:07 +07:00
|
|
|
return kzalloc_node(sizeof(struct nvm_dev), GFP_KERNEL, node);
|
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-29 01:54:55 +07:00
|
|
|
}
|
2016-09-16 19:25:07 +07:00
|
|
|
EXPORT_SYMBOL(nvm_alloc_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-29 01:54:55 +07:00
|
|
|
|
2016-09-16 19:25:07 +07:00
|
|
|
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-29 01:54:55 +07:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = nvm_init(dev);
|
|
|
|
if (ret)
|
|
|
|
goto err_init;
|
|
|
|
|
2015-11-28 22:49:25 +07:00
|
|
|
if (dev->ops->max_phys_sect > 256) {
|
|
|
|
pr_info("nvm: max sectors supported is 256.\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_init;
|
|
|
|
}
|
|
|
|
|
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-29 01:54:55 +07:00
|
|
|
if (dev->ops->max_phys_sect > 1) {
|
2016-05-07 01:03:13 +07:00
|
|
|
dev->dma_pool = dev->ops->create_dma_pool(dev, "ppalist");
|
|
|
|
if (!dev->dma_pool) {
|
|
|
|
pr_err("nvm: could not create dma pool\n");
|
2015-11-20 19:47:54 +07:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_init;
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-04 21:13:27 +07:00
|
|
|
if (dev->identity.cap & NVM_ID_DCAP_BBLKMGMT) {
|
|
|
|
ret = nvm_get_sysblock(dev, &dev->sb);
|
|
|
|
if (!ret)
|
|
|
|
pr_err("nvm: device not initialized.\n");
|
|
|
|
else if (ret < 0)
|
|
|
|
pr_err("nvm: err (%d) on device initialization\n", ret);
|
|
|
|
}
|
2016-01-12 13:49:38 +07:00
|
|
|
|
2015-12-06 17:25:49 +07:00
|
|
|
/* register device with a supported media manager */
|
2015-11-16 21:34:42 +07:00
|
|
|
down_write(&nvm_lock);
|
2016-01-12 13:49:38 +07:00
|
|
|
if (ret > 0)
|
|
|
|
dev->mt = nvm_init_mgr(dev);
|
2015-11-16 21:34:42 +07:00
|
|
|
list_add(&dev->devices, &nvm_devices);
|
|
|
|
up_write(&nvm_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-29 01:54:55 +07:00
|
|
|
return 0;
|
|
|
|
err_init:
|
2016-03-03 21:06:38 +07:00
|
|
|
kfree(dev->lun_map);
|
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-29 01:54:55 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_register);
|
|
|
|
|
2016-09-16 19:25:07 +07:00
|
|
|
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-29 01:54:55 +07:00
|
|
|
{
|
2015-11-28 22:49:28 +07:00
|
|
|
down_write(&nvm_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-29 01:54:55 +07:00
|
|
|
list_del(&dev->devices);
|
|
|
|
up_write(&nvm_lock);
|
2015-11-16 21:34:43 +07:00
|
|
|
|
2016-11-29 04:38:53 +07:00
|
|
|
nvm_free(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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nvm_unregister);
|
|
|
|
|
|
|
|
static int __nvm_configure_create(struct nvm_ioctl_create *create)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev;
|
|
|
|
struct nvm_ioctl_create_simple *s;
|
|
|
|
|
2015-11-28 22:49:28 +07:00
|
|
|
down_write(&nvm_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-29 01:54:55 +07:00
|
|
|
dev = nvm_find_nvm_dev(create->dev);
|
2015-11-28 22:49:28 +07:00
|
|
|
up_write(&nvm_lock);
|
2016-07-07 14:54:16 +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-29 01:54:55 +07:00
|
|
|
if (!dev) {
|
|
|
|
pr_err("nvm: device not found\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
if (!dev->mt) {
|
|
|
|
pr_info("nvm: device has no media manager registered.\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
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-29 01:54:55 +07:00
|
|
|
if (create->conf.type != NVM_CONFIG_TYPE_SIMPLE) {
|
|
|
|
pr_err("nvm: config type not valid\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
s = &create->conf.s;
|
|
|
|
|
2016-11-29 04:39:06 +07:00
|
|
|
if (s->lun_begin > s->lun_end || s->lun_end > dev->geo.nr_luns) {
|
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-29 01:54:55 +07:00
|
|
|
pr_err("nvm: lun out of bound (%u:%u > %u)\n",
|
2016-11-29 04:39:06 +07:00
|
|
|
s->lun_begin, s->lun_end, dev->geo.nr_luns);
|
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-29 01:54:55 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
return dev->mt->create_tgt(dev, create);
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static long nvm_ioctl_info(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_info *info;
|
|
|
|
struct nvm_tgt_type *tt;
|
|
|
|
int tgt_iter = 0;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
info = memdup_user(arg, sizeof(struct nvm_ioctl_info));
|
|
|
|
if (IS_ERR(info))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
info->version[0] = NVM_VERSION_MAJOR;
|
|
|
|
info->version[1] = NVM_VERSION_MINOR;
|
|
|
|
info->version[2] = NVM_VERSION_PATCH;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
2016-05-07 01:03:02 +07:00
|
|
|
list_for_each_entry(tt, &nvm_tgt_types, 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-29 01:54:55 +07:00
|
|
|
struct nvm_ioctl_info_tgt *tgt = &info->tgts[tgt_iter];
|
|
|
|
|
|
|
|
tgt->version[0] = tt->version[0];
|
|
|
|
tgt->version[1] = tt->version[1];
|
|
|
|
tgt->version[2] = tt->version[2];
|
|
|
|
strncpy(tgt->tgtname, tt->name, NVM_TTYPE_NAME_MAX);
|
|
|
|
|
|
|
|
tgt_iter++;
|
|
|
|
}
|
|
|
|
|
|
|
|
info->tgtsize = tgt_iter;
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
|
2015-11-28 22:49:24 +07:00
|
|
|
if (copy_to_user(arg, info, sizeof(struct nvm_ioctl_info))) {
|
|
|
|
kfree(info);
|
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-29 01:54:55 +07:00
|
|
|
return -EFAULT;
|
2015-11-28 22:49:24 +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-29 01:54:55 +07:00
|
|
|
|
|
|
|
kfree(info);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static long nvm_ioctl_get_devices(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_get_devices *devices;
|
|
|
|
struct nvm_dev *dev;
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
devices = kzalloc(sizeof(struct nvm_ioctl_get_devices), GFP_KERNEL);
|
|
|
|
if (!devices)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
list_for_each_entry(dev, &nvm_devices, devices) {
|
|
|
|
struct nvm_ioctl_device_info *info = &devices->info[i];
|
|
|
|
|
|
|
|
sprintf(info->devname, "%s", dev->name);
|
|
|
|
if (dev->mt) {
|
|
|
|
info->bmversion[0] = dev->mt->version[0];
|
|
|
|
info->bmversion[1] = dev->mt->version[1];
|
|
|
|
info->bmversion[2] = dev->mt->version[2];
|
|
|
|
sprintf(info->bmname, "%s", dev->mt->name);
|
|
|
|
} else {
|
|
|
|
sprintf(info->bmname, "none");
|
|
|
|
}
|
|
|
|
|
|
|
|
i++;
|
|
|
|
if (i > 31) {
|
|
|
|
pr_err("nvm: max 31 devices can be reported.\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
|
|
|
|
devices->nr_devices = i;
|
|
|
|
|
2015-11-28 22:49:24 +07:00
|
|
|
if (copy_to_user(arg, devices,
|
|
|
|
sizeof(struct nvm_ioctl_get_devices))) {
|
|
|
|
kfree(devices);
|
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-29 01:54:55 +07:00
|
|
|
return -EFAULT;
|
2015-11-28 22:49:24 +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-29 01:54:55 +07:00
|
|
|
|
|
|
|
kfree(devices);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static long nvm_ioctl_dev_create(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_create create;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (copy_from_user(&create, arg, sizeof(struct nvm_ioctl_create)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
create.dev[DISK_NAME_LEN - 1] = '\0';
|
|
|
|
create.tgttype[NVM_TTYPE_NAME_MAX - 1] = '\0';
|
|
|
|
create.tgtname[DISK_NAME_LEN - 1] = '\0';
|
|
|
|
|
|
|
|
if (create.flags != 0) {
|
|
|
|
pr_err("nvm: no flags supported\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __nvm_configure_create(&create);
|
|
|
|
}
|
|
|
|
|
|
|
|
static long nvm_ioctl_dev_remove(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_remove remove;
|
2016-07-07 14:54:16 +07:00
|
|
|
struct nvm_dev *dev;
|
|
|
|
int ret = 0;
|
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-29 01:54:55 +07:00
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (copy_from_user(&remove, arg, sizeof(struct nvm_ioctl_remove)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
remove.tgtname[DISK_NAME_LEN - 1] = '\0';
|
|
|
|
|
|
|
|
if (remove.flags != 0) {
|
|
|
|
pr_err("nvm: no flags supported\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-07-07 14:54:16 +07:00
|
|
|
list_for_each_entry(dev, &nvm_devices, devices) {
|
|
|
|
ret = dev->mt->remove_tgt(dev, &remove);
|
|
|
|
if (!ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
|
2016-01-12 13:49:37 +07:00
|
|
|
static void nvm_setup_nvm_sb_info(struct nvm_sb_info *info)
|
|
|
|
{
|
|
|
|
info->seqnr = 1;
|
|
|
|
info->erase_cnt = 0;
|
|
|
|
info->version = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static long __nvm_ioctl_dev_init(struct nvm_ioctl_dev_init *init)
|
|
|
|
{
|
|
|
|
struct nvm_dev *dev;
|
|
|
|
struct nvm_sb_info info;
|
2016-01-12 13:49:38 +07:00
|
|
|
int ret;
|
2016-01-12 13:49:37 +07:00
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
dev = nvm_find_nvm_dev(init->dev);
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
if (!dev) {
|
|
|
|
pr_err("nvm: device not found\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
nvm_setup_nvm_sb_info(&info);
|
|
|
|
|
|
|
|
strncpy(info.mmtype, init->mmtype, NVM_MMTYPE_LEN);
|
|
|
|
info.fs_ppa.ppa = -1;
|
|
|
|
|
2016-02-04 21:13:27 +07:00
|
|
|
if (dev->identity.cap & NVM_ID_DCAP_BBLKMGMT) {
|
|
|
|
ret = nvm_init_sysblock(dev, &info);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2016-01-12 13:49:38 +07:00
|
|
|
|
|
|
|
memcpy(&dev->sb, &info, sizeof(struct nvm_sb_info));
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
dev->mt = nvm_init_mgr(dev);
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
|
|
|
|
return 0;
|
2016-01-12 13:49:37 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static long nvm_ioctl_dev_init(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_dev_init init;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (copy_from_user(&init, arg, sizeof(struct nvm_ioctl_dev_init)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (init.flags != 0) {
|
|
|
|
pr_err("nvm: no flags supported\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
init.dev[DISK_NAME_LEN - 1] = '\0';
|
|
|
|
|
|
|
|
return __nvm_ioctl_dev_init(&init);
|
|
|
|
}
|
|
|
|
|
2016-01-12 13:49:39 +07:00
|
|
|
static long nvm_ioctl_dev_factory(struct file *file, void __user *arg)
|
|
|
|
{
|
|
|
|
struct nvm_ioctl_dev_factory fact;
|
|
|
|
struct nvm_dev *dev;
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (copy_from_user(&fact, arg, sizeof(struct nvm_ioctl_dev_factory)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
fact.dev[DISK_NAME_LEN - 1] = '\0';
|
|
|
|
|
|
|
|
if (fact.flags & ~(NVM_FACTORY_NR_BITS - 1))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
down_write(&nvm_lock);
|
|
|
|
dev = nvm_find_nvm_dev(fact.dev);
|
|
|
|
up_write(&nvm_lock);
|
|
|
|
if (!dev) {
|
|
|
|
pr_err("nvm: device not found\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-05-07 01:03:17 +07:00
|
|
|
nvm_free_mgr(dev);
|
2016-01-12 13:49:39 +07:00
|
|
|
|
2016-02-04 21:13:27 +07:00
|
|
|
if (dev->identity.cap & NVM_ID_DCAP_BBLKMGMT)
|
|
|
|
return nvm_dev_factory(dev, fact.flags);
|
|
|
|
|
|
|
|
return 0;
|
2016-01-12 13:49:39 +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-29 01:54:55 +07:00
|
|
|
static long nvm_ctl_ioctl(struct file *file, uint cmd, unsigned long arg)
|
|
|
|
{
|
|
|
|
void __user *argp = (void __user *)arg;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case NVM_INFO:
|
|
|
|
return nvm_ioctl_info(file, argp);
|
|
|
|
case NVM_GET_DEVICES:
|
|
|
|
return nvm_ioctl_get_devices(file, argp);
|
|
|
|
case NVM_DEV_CREATE:
|
|
|
|
return nvm_ioctl_dev_create(file, argp);
|
|
|
|
case NVM_DEV_REMOVE:
|
|
|
|
return nvm_ioctl_dev_remove(file, argp);
|
2016-01-12 13:49:37 +07:00
|
|
|
case NVM_DEV_INIT:
|
|
|
|
return nvm_ioctl_dev_init(file, argp);
|
2016-01-12 13:49:39 +07:00
|
|
|
case NVM_DEV_FACTORY:
|
|
|
|
return nvm_ioctl_dev_factory(file, argp);
|
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-29 01:54:55 +07:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations _ctl_fops = {
|
|
|
|
.open = nonseekable_open,
|
|
|
|
.unlocked_ioctl = nvm_ctl_ioctl,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.llseek = noop_llseek,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct miscdevice _nvm_misc = {
|
|
|
|
.minor = MISC_DYNAMIC_MINOR,
|
|
|
|
.name = "lightnvm",
|
|
|
|
.nodename = "lightnvm/control",
|
|
|
|
.fops = &_ctl_fops,
|
|
|
|
};
|
2016-10-30 03:38:41 +07:00
|
|
|
builtin_misc_device(_nvm_misc);
|