Virtio-blk extended lifetime feature

Virtio-blk extended lifetime feature

[Alvaro Karsz]

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.

(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

Virtio-blk extended lifetime feature

[Alvaro Karsz]

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.

(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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[dm-devel] Virtio-blk extended lifetime feature

[Alvaro Karsz]

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.

(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

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

Re: Virtio-blk extended lifetime feature

[Enrico Granata]

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@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.
>
> (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

Re: [dm-devel] Virtio-blk extended lifetime feature

[Enrico Granata]

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@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.
>
> (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

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

Re: Virtio-blk extended lifetime feature

[Chaitanya Kulkarni]

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@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

Re: [dm-devel] Virtio-blk extended lifetime feature

[Chaitanya Kulkarni]

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@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
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

Re: Virtio-blk extended lifetime feature

[Enrico Granata]

On Wed, Jan 18, 2023 at 12:46 PM Chaitanya Kulkarni
<chaitanyak@nvidia.com> wrote:
>
> 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@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.

What do you think about my proposal to have a single "wear estimate"
field and allow each flash type to calculate it as required by its own
internal logic?
The migration for eMMC and existing drivers would be to expose the
maximum of type_A, type_B wear, but other cell types would be able to
provide whatever logic they need as long as it meaningfully exposes
the "wear"

>
> >>
> >> (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

Re: [dm-devel] Virtio-blk extended lifetime feature

[Enrico Granata]

On Wed, Jan 18, 2023 at 12:46 PM Chaitanya Kulkarni
<chaitanyak@nvidia.com> wrote:
>
> 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@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.

What do you think about my proposal to have a single "wear estimate"
field and allow each flash type to calculate it as required by its own
internal logic?
The migration for eMMC and existing drivers would be to expose the
maximum of type_A, type_B wear, but other cell types would be able to
provide whatever logic they need as long as it meaningfully exposes
the "wear"

>
> >>
> >> (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

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel