Virtio-blk extended lifetime feature
Chaitanya Kulkarni
chaitanyak at nvidia.com
Wed Jan 18 11:46:54 PST 2023
On 1/17/23 14:30, Enrico Granata wrote:
> Hi,
> I am going to add +Jahdiel Alvarez who is also looking into a similar
> issue, and also I would like to hear thoughts of people who may have
> worked with (embedded or otherwise) storage more recently than I have
>
> One thought that Jahdiel and myself were pondering is whether we need
> "type_a" and "type_b" fields at all, or if there should simply be a
> "wear estimate" field, which for eMMC, it could be max(typ_a, typ_b)
> but it could generalize to any number of cell or other algorithm, as
> long as it produces one unique estimate of wear
>
> Thanks,
> - Enrico
>
> Thanks,
> - Enrico
>
>
> On Sun, Jan 15, 2023 at 12:56 AM Alvaro Karsz
> <alvaro.karsz at solid-run.com> wrote:
>>
>> Hi guys,
>>
>> While trying to upstream the implementation of VIRTIO_BLK_F_LIFETIME
>> feature, many developers suggested that this feature should be
>> extended to include more cell types, since its current implementation
>> in virtio spec is relevant for MMC and UFS devices only.
>>
>> The VIRTIO_BLK_F_LIFETIME defines the following fields:
>>
>> - pre_eol_info: the percentage of reserved blocks that are consumed.
>> - device_lifetime_est_typ_a: wear of SLC cells.
>> - device_lifetime_est_typ_b: wear of MLC cells.
For immediate comments :-
It needs to cover all the flash cell types.
Using names like type_a/type_b in the spec and in the implementation
adds unnecessary confusion and requires extra documentation in the
code that needs to be changed.
>>
>> (https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html)
>>
>> Following Michael's suggestion, I'd like to add to the virtio spec
>> with a new, extended lifetime command.
>> Since I'm more familiar with embedded type storage devices, I'd like
>> to ask you guys what fields you think should be included in the
>> extended command.
>>
>> Thanks,
>>
>> Alvaro
-ck
More information about the Linux-nvme
mailing list