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