On Wed, Jan 18, 2023 at 12:46 PM Chaitanya Kulkarni <chaitanyak@xxxxxxxxxx> 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@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. 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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
