Hi, Currently a device is brought up via the media manager, which detects if a device supports it. We like to allow a drive to be intialized to a specific media manager and therefore introduce new functionality in the core to scan a specific set of flash blocks, that maintains what we call system blocks. With this patchset, the disk should first be initialized to a given media manager, which then takes control over the device. The core and media managers are free to update the system block for the device. In the case of the initialization PPA for the media manager is changed or for other reasons. A system block is duplicated in three places to prevent the system block data to be unreachable. We currently allocate blocks on three different luns, the first lun from the first channel, the first lun from the middle channel, and from the first lun in the last channel. If a device only have a single or two channels, only one or two system blocks are maintained. The three luns each have two blocks reserved during initialization, which amounts to approximately 1.5M updates in total, which is much more updates that we expect with current workloads. The first four patches prepares the core to directlt interact with the device, and the last patch introduces the recovery scheme. Later patches will add the management functionality and integrate with the gennvm media manager. Thanks, Matias Matias Bjørling (5): lightnvm: move ppa erase logic to core lightnvm: refactor rqd ppa list into set/free lightnvm: add sync support for submit_io lightnvm: introduce nvm_submit_ppa lightnvm: core on-disk initialization drivers/lightnvm/Makefile | 2 +- drivers/lightnvm/core.c | 128 +++++++++++ drivers/lightnvm/gennvm.c | 68 +----- drivers/lightnvm/sysblk.c | 524 +++++++++++++++++++++++++++++++++++++++++++ drivers/nvme/host/lightnvm.c | 7 + include/linux/lightnvm.h | 39 ++++ 6 files changed, 703 insertions(+), 65 deletions(-) create mode 100644 drivers/lightnvm/sysblk.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
