On 31.03.2021 21:40, Bean Huo wrote:
Hi Martin
I don't know when/how do you plan to accept this patch. I think the
Mobile vendors and chipset vendors are all looking forward to this UFS
HPB feature that can be mainlined in the upstream Linux. Since the
first version HPB driver submitted in the c
On 20.08.2020 13:07, Kanchan Joshi wrote:
On Thu, Aug 20, 2020 at 3:22 AM Keith Busch wrote:
On Wed, Aug 19, 2020 at 01:11:58PM -0600, David Fugate wrote:
> Intel does not support making *optional* NVMe spec features *required*
> by the NVMe driver.
This is inaccurate. As another example, the
On 20.08.2020 08:52, Christoph Hellwig wrote:
On Thu, Aug 20, 2020 at 08:37:19AM +0200, Javier Gonzalez wrote:
We will stop pushing for this emulation. We have a couple of SSDs where
we disabled Append, we implemented support for them, and we wanted to
push the changes upstream. That's it.
On 19.08.2020 12:43, Christoph Hellwig wrote:
On Wed, Aug 19, 2020 at 09:14:13AM +, Damien Le Moal wrote:
While defining a zone append command for SCSI/ZBC is possible (using sense data
for returning the written offset), there is no way to define zone append for
SATA/ZAC without entirely bre
On 19.08.2020 13:25, Jens Axboe wrote:
On 8/19/20 12:11 PM, David Fugate wrote:
On Tue, 2020-08-18 at 07:12 +, Christoph Hellwig wrote:
On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote:
If drive does not support zone-append natively, enable emulation
using
regular write.
Make
On 19.08.2020 09:40, Christoph Hellwig wrote:
On Tue, Aug 18, 2020 at 08:04:28PM +0200, Javier Gonzalez wrote:
I understand that you want vendor alignment in the NVMe driver and I
agree. We are not pushing for a non-append model - you can see that we
are investing effort in implementing the
On 18.08.2020 10:39, Keith Busch wrote:
On Tue, Aug 18, 2020 at 07:29:12PM +0200, Javier Gonzalez wrote:
On 18.08.2020 09:58, Keith Busch wrote:
> On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote:
> > a number of customers are requiring the use of normal writes, which we
On 18.08.2020 12:51, Matias Bjørling wrote:
On 18/08/2020 11.50, Javier Gonzalez wrote:
On 18.08.2020 09:12, Christoph Hellwig wrote:
On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote:
If drive does not support zone-append natively, enable emulation using
regular write.
Make
On 18.08.2020 17:50, Christoph Hellwig wrote:
On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote:
I understand that the NVMe process was agitated and that the current ZNS
implementation in Linux relies in append support from the device
perspective. However, the current TP does
On 18.08.2020 09:58, Keith Busch wrote:
On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote:
a number of customers are requiring the use of normal writes, which we
want to support.
A device that supports append is completely usable for those customers,
too. There's no ne
On 18.08.2020 09:12, Christoph Hellwig wrote:
On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote:
If drive does not support zone-append natively, enable emulation using
regular write.
Make emulated zone-append cmd write-lock the zone, preventing
concurrent append/write on the same zon
> On 29 Aug 2018, at 15.02, Matias Bjørling wrote:
>
> On 08/29/2018 10:56 AM, Javier González wrote:
>> pblk maintains two different metadata paths for smeta and emeta, which
>> store metadata at the start of the line and at the end of the line,
>> respectively. Until now, these path has been c
> On 2 Aug 2018, at 22.50, Matias Bjørling wrote:
>
> rqd.error is masked by the return value of pblk_submit_io_sync.
> The rqd structure is then passed on to the end_io function, which
> assumes that any error should lead to a chunk being marked
> offline/bad. Since the pblk_submit_io_sync can f
> On 29 Jun 2018, at 13.22, Matias Bjørling wrote:
>
> On 06/29/2018 01:07 PM, Javier Gonzalez wrote:
>>> On 29 Jun 2018, at 12.59, Matias Bjørling wrote:
>>>
>>> On 06/29/2018 11:36 AM, Javier Gonzalez wrote:
>>>>> On 28 Jun 2018, at 15
> On 12 Jun 2018, at 03.30, Matias Bjørling wrote:
>
> For devices that does not specify a limit on its transfer size, the
> get_chk_meta command may send down a single I/O retrieving the full
> chunk metadata table. Resulting in large 2-4MB I/O requests. Instead,
> split up the I/Os to a maximum
Javier
I somehow missed these patches in the mailing list. Sorry for coming
with feedback this late. I'll look at my filters - in any case, would
you mind Cc'ing me in the future?
> On 28 May 2018, at 10.58, Matias Bjørling wrote:
>
> From: Igor Konopko
>
> During sequential workloads we can
> On 28 May 2018, at 10.58, Matias Bjørling wrote:
>
> From: Igor Konopko
>
> When all the blocks (chunks) in line are marked as bad (offline)
> we shouldn't try to read smeta during init process.
>
> Currently we are trying to do so by passing -1 as PPA address,
> what causes multiple warning
> On 28 May 2018, at 10.58, Matias Bjørling wrote:
>
> From: Marcin Dziegielewski
>
> Some devices can expose mw_cunits equal to 0, it can cause creation
> of too small write buffer and cause performance to drop on write
> workloads.
>
> To handle that, we use the default value for MLC and bea
> On 21 May 2018, at 00.25, Kent Overstreet wrote:
>
> Signed-off-by: Kent Overstreet
> ---
> drivers/lightnvm/pblk-core.c | 30 ++---
> drivers/lightnvm/pblk-init.c | 72
> drivers/lightnvm/pblk-read.c | 4 +-
> drivers/lightnvm/pblk-recovery.c
> On 24 Apr 2018, at 07.45, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> Smeta write errors were previously ignored. Skip these
> lines instead and throw them back on the free
> list, so the chunks will go through a reset cycle
> before we attempt to use the line again.
>
> Signed-off-b
> On 30 Apr 2018, at 11.14, Javier Gonzalez wrote:
>
>> On 24 Apr 2018, at 07.45, Hans Holmberg
>> wrote:
>>
>> From: Hans Holmberg
>>
>> Write failures should not happen under normal circumstances,
>> so in order to bring the chunk back int
> On 24 Apr 2018, at 07.45, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> Write failures should not happen under normal circumstances,
> so in order to bring the chunk back into a known state as soon
> as possible, evacuate all the valid data out of the line and let the
> fw judge if the
> On 24 Apr 2018, at 07.45, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> The write error recovery path is incomplete, so rework
> the write error recovery handling to do resubmits directly
> from the write buffer.
>
> When a write error occurs, the remaining sectors in the chunk are
> m
> On 28 Apr 2018, at 21.31, Matias Bjørling wrote:
>
> On 4/23/18 10:45 PM, Hans Holmberg wrote:
>> From: Hans Holmberg
>> This patch series fixes the(currently incomplete) write error handling
>> in pblk by:
>> * queuing and re-submitting failed writes in the write buffer
>> * evacuating vali
> On 19 Apr 2018, at 09.39, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> Smeta write errors were previously ignored. Skip these
> lines instead and throw them back on the free
> list, so the chunks will go through a reset cycle
> before we attempt to use the line again.
>
> Signed-off-b
> On 19 Apr 2018, at 09.39, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> Write failures should not happen under normal circumstances,
> so in order to bring the chunk back into a known state as soon
> as possible, evacuate all the valid data out of the line and let the
> fw judge if the
> On 19 Apr 2018, at 09.39, Hans Holmberg
> wrote:
>
> From: Hans Holmberg
>
> The write error recovery path is incomplete, so rework
> the write error recovery handling to do resubmits directly
> from the write buffer.
>
> When a write error occurs, the remaining sectors in the chunk are
> m
> On 17 Apr 2018, at 05.11, Matias Bjørling wrote:
>
> On 4/16/18 12:25 PM, Javier González wrote:
>> Remove unnecessary indirection on the read path.
>
> Title and description are the same. Can you elaborate what changed
> since pblk_submit_io now directly can be returned, and doesn't have
> it
> On 17 Apr 2018, at 03.55, Wei Xu wrote:
>
> Add a new lightnvm quirk to identify CNEX’s Granby controller.
>
> Signed-off-by: Wei Xu
> ---
> drivers/nvme/host/pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index cb73bc8..94
> On 21 Mar 2018, at 20.27, Matias Bjørling wrote:
>
>> On 03/21/2018 03:36 PM, Keith Busch wrote:
>> On Wed, Mar 21, 2018 at 03:06:05AM -0700, Matias Bjørling wrote:
outside of nvme core so that we can use it form lightnvm.
Signed-off-by: Javier González
---
drivers
> On 1 Mar 2018, at 12.51, Matias Bjørling wrote:
>
> On 03/01/2018 12:02 PM, Javier Gonzalez wrote:
>>> On 1 Mar 2018, at 11.40, Matias Bjørling wrote:
>>>
>>> On 02/28/2018 04:49 PM, Javier González wrote:
>>>> The 2.0 spec provides a report
> On 1 Mar 2018, at 11.40, Matias Bjørling wrote:
>
> On 02/28/2018 04:49 PM, Javier González wrote:
>> The 2.0 spec provides a report chunk log page that can be retrieved
>> using the stangard nvme get log page. This replaces the dedicated
>> get/put bad block table in 1.2.
>> This patch impleme
> On 27 Feb 2018, at 19.23, Matias Bjørling wrote:
>
> On 02/27/2018 04:57 PM, Javier González wrote:
>> Currently, the device geometry is stored redundantly in the nvm_id and
>> nvm_geo structures at a device level. Moreover, when instantiating
>> targets on a specific number of LUNs, these str
> On 27 Feb 2018, at 16.57, Javier González wrote:
>
> Currently, the device geometry is stored redundantly in the nvm_id and
> nvm_geo structures at a device level. Moreover, when instantiating
> targets on a specific number of LUNs, these structures are replicated
> and manually modified to fi
> On 26 Feb 2018, at 19.24, Matias Bjørling wrote:
>
> On 02/26/2018 07:21 PM, Javier Gonzalez wrote:
>>> On 26 Feb 2018, at 19.19, Matias Bjørling wrote:
>>>
>>> On 02/26/2018 02:16 PM, Javier González wrote:
>>>> # Changes since V2:
>>&g
> On 26 Feb 2018, at 19.19, Matias Bjørling wrote:
>
> On 02/26/2018 02:16 PM, Javier González wrote:
>> # Changes since V2:
>> Apply Matias' feedback:
>> - Remove generic nvm_id identify structure.
>> - Do not remap capabilities (cap) to media and controlled capabilities
>>(mccap). Instead
> On 26 Feb 2018, at 19.20, Matias Bjørling wrote:
>
> On 02/26/2018 02:18 PM, Javier González wrote:
>> Remove unused variable after a previous cleanup (a8112b631adb)
>> Signed-off-by: Javier González
>> ---
>> drivers/lightnvm/pblk-core.c | 3 ---
>> 1 file changed, 3 deletions(-)
>> diff --
> On 13 Feb 2018, at 13.49, Matias Bjørling wrote:
>
> NVMe 1.2.1 extends the get log page interface to include 64 bit
> offset and increases the number of dwords to 32 bits. Implement
> for future use.
>
> Signed-off-by: Matias Bjørling
> ---
> drivers/nvme/host/core.c | 36 +++
> On 22 Feb 2018, at 13.22, Matias Bjørling wrote:
>
> On 02/22/2018 08:44 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 08.25, Matias Bjørling wrote:
>>>
>>> On 02/21/2018 10:26 AM, Javier González wrote:
>>>> Currently, the device
> On 22 Feb 2018, at 12.10, Matias Bjørling wrote:
>
> On 02/22/2018 11:25 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 10.39, Matias Bjørling wrote:
>>>
>>> On 02/22/2018 08:47 AM, Javier Gonzalez wrote:
>>>>> On 22 Feb 2018, at 08.28,
> On 22 Feb 2018, at 10.39, Matias Bjørling wrote:
>
> On 02/22/2018 08:47 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 08.28, Matias Bjørling wrote:
>>>
>>>> On 02/21/2018 10:26 AM, Javier González wrote:
>>>> Both 1.2 an
Javier
> On 22 Feb 2018, at 11.00, Matias Bjørling wrote:
>
> On 02/22/2018 10:52 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 10.45, Matias Bjørling wrote:
>>>
>>> On 02/22/2018 08:55 AM, Javier Gonzalez wrote:
>>>>> On 22 Feb 2018, a
> On 22 Feb 2018, at 10.45, Matias Bjørling wrote:
>
> On 02/22/2018 08:55 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 08.45, Matias Bjørling wrote:
>>>
>>> On 02/21/2018 10:26 AM, Javier González wrote:
>>>> Complete the generic geometry
> On 22 Feb 2018, at 08.45, Matias Bjørling wrote:
>
> On 02/21/2018 10:26 AM, Javier González wrote:
>> Complete the generic geometry structure with the maxoc and maxocpu
>> felds, present in the 2.0 spec.
>> Signed-off-by: Javier González
>> ---
>> drivers/nvme/host/lightnvm.c | 4
>> in
> On 22 Feb 2018, at 08.28, Matias Bjørling wrote:
>
> On 02/21/2018 10:26 AM, Javier González wrote:
>> Both 1.2 and 2.0 specs define a field for media and controller
>> capabilities. Also, 1.2 defines a separate field dedicated to device
>> capabilities.
>> In 2.0 sysfs, this values have been m
> On 22 Feb 2018, at 08.25, Matias Bjørling wrote:
>
> On 02/21/2018 10:26 AM, Javier González wrote:
>> Currently, the device geometry is stored redundantly in the nvm_id and
>> nvm_geo structures at a device level. Moreover, when instantiating
>> targets on a specific number of LUNs, these str
> On 15 Feb 2018, at 14.11, Matias Bjørling wrote:
>
> A couple of patches for 2.0 support for the lightnvm subsystem. They
> form the foundation for the integration.
>
> The first two patches is preparation for the 2.0 work. The third patch
> implements the 2.0 data structures, the geometry com
> On 19 Feb 2018, at 08.31, Matias Bjørling wrote:
>
> On 02/16/2018 07:48 AM, Javier Gonzalez wrote:
>>> On 15 Feb 2018, at 05.11, Matias Bjørling wrote:
>>>
>>> The value of max_phys_sect is always static. Instead of
>>> defining it in the
> On 15 Feb 2018, at 05.11, Matias Bjørling wrote:
>
> The value of max_phys_sect is always static. Instead of
> defining it in the nvm_dev_ops structure, declare it as a global
> value.
>
> Signed-off-by: Matias Bjørling
> ---
> drivers/lightnvm/core.c | 28 +++---
> On 15 Feb 2018, at 02.20, Matias Bjørling wrote:
>
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González
>> Apart from showing the geometry returned by the different identify
>> commands, provide the generic geometry too, as this is the geometry that
>> targets will use to
> On 15 Feb 2018, at 02.13, Matias Bjørling wrote:
>
>> On 02/13/2018 03:06 PM, Javier González wrote:
>> With the inclusion of 2.0 support, we need a generic geometry that
>> describes the OCSSD independently of the specification that it
>> implements. Otherwise, geometry specific code is requi
> On 9 Feb 2018, at 01.27, Matias Bjørling wrote:
>
> The nvme driver sets up the size of the nvme namespace in two steps.
> First it initializes the device with standard logical block and
> metadata sizes, and then sets the correct logical block and metadata
> size. Due to the OCSSD 2.0 specifi
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote:
>
> Implement the geometry data structures for 2.0 and enable a drive
> to be identified as one, including exposing the appropriate 2.0
> sysfs entries.
>
> Signed-off-by: Matias Bjørling
> ---
> drivers/lightnvm/core.c | 2 +-
> drivers/n
> On 5 Feb 2018, at 13.15, Matias Bjørling wrote:
>
> Hi,
>
> A couple of patches for 2.0 support for the lightnvm subsystem. They
> form the basis for integrating 2.0 support.
>
> For the rest of the support, Javier has code that implements report
> chunk and sets up the LBA format data struct
> On 4 Feb 2018, at 13.55, Matias Bjørling wrote:
>
> On 02/04/2018 11:37 AM, Javier Gonzalez wrote:
>>> On 31 Jan 2018, at 19.24, Matias Bjørling wrote:
>>>
>>> On 01/31/2018 10:13 AM, Javier Gonzalez wrote:
>>>>> On 31 Jan 2018, at 16.51, M
> On 31 Jan 2018, at 19.24, Matias Bjørling wrote:
>
> On 01/31/2018 10:13 AM, Javier Gonzalez wrote:
>>> On 31 Jan 2018, at 16.51, Matias Bjørling wrote:
>>>
>> I have a patches abstracting this, which I think it makes it cleaner. I can
>> push it n
> On 31 Jan 2018, at 16.51, Matias Bjørling wrote:
>
>> On 01/31/2018 03:06 AM, Javier González wrote:
>> In preparation for the OCSSD 2.0 spec. bad block identification,
>> refactor the current code to generalize bad block get/set functions and
>> structures.
>> Signed-off-by: Javier González
> On 5 Jan 2018, at 20.53, Matias Bjørling wrote:
>
> On 01/05/2018 08:52 PM, Javier Gonzalez wrote:
>>> On 5 Jan 2018, at 20.33, Randy Dunlap wrote:
>>>
>>> On 01/05/2018 05:16 AM, Matias Bjørling wrote:
>>>> From: Javier González
>>
> On 5 Jan 2018, at 20.33, Randy Dunlap wrote:
>
> On 01/05/2018 05:16 AM, Matias Bjørling wrote:
>> From: Javier González
>>
>> Allow to set the over-provision percentage on target creation. In case
>> that the value is not provided, fall back to the default value set by
>> the target.
>>
>>
>
> On 13 May 2017, at 21.50, Rakesh Pandit wrote:
>
> While creating new device with NVM_DEV_CREATE if LUNs are already
> allocated ioctl would return -ENOMEM which is wrong. This patch
> propagates -EBUSY from nvm_reserve_luns which is correct response.
>
> Fixes: ade69e243 ("lightnvm: merge
Hi Bart,
> On 10 Apr 2017, at 22.35, Bart Van Assche wrote:
>
> On 04/10/2017 11:36 AM, Javier González wrote:
>> Changes since v3:
>> * Apply Bart's feedback [1]
>
> Thanks for having addressed these comments. But please also make sure
> that the pblk driver builds cleanly with W=1 C=2. When r
Add missing check after mempool allocation.
Signed-off-by: Javier Gonzalez
---
drivers/lightnvm/rrpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index a1e7488..f4bc986 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm
Add free block, used block, and bad block information to the show debug
interface. This information is used to debug how targets track blocks.
Also, change debug function name to make it more generic.
Signed-off-by: Javier Gonzalez
---
drivers/lightnvm/core.c | 2 +-
drivers/lightnvm
free list
when the device is booted.
Signed-off-by: Javier Gonzalez
---
drivers/lightnvm/gennvm.c | 14 +-
include/linux/lightnvm.h | 2 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index c0d0eb2..43c01e0 100644
64 matches
Mail list logo
