[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <B49B713F-1E73-44B1-BFB1-34D91EC6A88C@cnexlabs.com>
Date: Mon, 8 Oct 2018 07:03:29 +0000
From: Javier Gonzalez <javier@...xlabs.com>
To: Matias Bjørling <mb@...htnvm.io>
CC: "javier@...igon.com" <javier@...igon.com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [V2 PATCH 0/2] lightnvm: pblk: retrieve chunk metadata on erase
> On 6 Oct 2018, at 03.13, Matias Bjørling <mb@...htnvm.io> wrote:
>
>> On 10/04/2018 09:13 AM, Javier González wrote:
>> Changes singe V1:
>> - remove sanity checks on the fast path
>> This patchset implements support for retrieving chunk metadata on reset.
>> This is the base for implementing wear-leveling and allowing chunks to
>> shrink at runtime.
>> Javier
>> Javier González (2):
>> lightnvm: pblk: add helper for printing chunk state
>> lightnvm: pblk: retrieve chunk metadata on erase
>> drivers/lightnvm/core.c | 44 ++++++++++++++++++++++++++++++++++--
>> drivers/lightnvm/pblk-core.c | 54 +++++++++++++++++++++++++++++++++-----------
>> drivers/lightnvm/pblk.h | 9 ++++++++
>> 3 files changed, 92 insertions(+), 15 deletions(-)
>
> Right now there isn't a way in the spec to tell if the drive supports this feature or not, and DSM Reset doesn't support it either. Making it a bug in the spec. Until the updated spec is out, I like to avoid adding this feature into the kernel.
Sure. It is the same bug we have when the read/write commands do not signal if the metadata pointer is set or not. This has not prevented current implementations of this feature though.
Anyway, I see the point; this not a critical thing, so let wait and get this fixed in the new spec release. There is a couple more bugs that I would like to fix. I’ll send you an email later this week.
For the DSM command seems more difficult as it would require changes to the nvme spec.
>
> The Get Log Page approach can be used for wear-levelling information.
Well, it is an unnecessary overhead to send a log page to pull the data. So let’s get it fixed.
> Similarly for knowing when a chunk shrink, pblk can't rely on a chunk not shrinking at runtime (and reporting early close error), so in the case this happens, pblk can either continue business as usual, or resync with the drive.
Sure, it’s different levels of handling and all paths should be implemented.
Thanks,
Javier
Powered by blists - more mailing lists