From: "Michael S. Tsirkin" <mst@redhat.com>
To: Enrico Granata <egranata@google.com>
Cc: virtio-dev@lists.oasis-open.org, hch@infradead.org,
linux-block@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] Provide detailed specification of virtio-blk lifetime metrics
Date: Wed, 5 May 2021 06:34:44 -0400 [thread overview]
Message-ID: <20210505062458-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20210502045740-mutt-send-email-mst@kernel.org>
On Sun, May 02, 2021 at 05:12:14AM -0400, Michael S. Tsirkin wrote:
> On Tue, Apr 20, 2021 at 04:25:56PM +0000, Enrico Granata wrote:
> > In the course of review, some concerns were surfaced about the
> > original virtio-blk lifetime proposal, as it depends on the eMMC
> > spec which is not open
> >
> > Add a more detailed description of the meaning of the fields
> > added by that proposal to the virtio-blk specification, as to
> > make it feasible to understand and implement the new lifetime
> > metrics feature without needing to refer to JEDEC's specification
> >
> > This patch does not change the meaning of those fields nor add
> > any new fields, but it is intended to provide an open and more
> > clear description of the meaning associated with those fields.
> >
> > Signed-off-by: Enrico Granata <egranata@google.com>
>
> Enrico it's great that you are reaching out to the
> wider storage community before making spec changes.
>
> Christoph could you please comment on whether this addresses
> your concerns with the lifetime feature.
> You wrote "it really needs to stand a lone and be properly documented"
> and this seems to be the direction this patch is going in.
>
>
> > ---
> > content.tex | 34 +++++++++++++++++++++++++++-------
> > 1 file changed, 27 insertions(+), 7 deletions(-)
> >
> > diff --git a/content.tex b/content.tex
> > index 9232d5c..7e14ccc 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -4669,13 +4669,32 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> > \end{lstlisting}
> >
> > The device lifetime metrics \field{pre_eol_info}, \field{device_lifetime_est_a}
> > -and \field{device_lifetime_est_b} have the semantics described by the JESD84-B50
> > -specification for the extended CSD register fields \field{PRE_EOL_INFO}
> > -\field{DEVICE_LIFETIME_EST_TYP_A} and \field{DEVICE_LIFETIME_EST_TYP_B}
> > -respectively.
> > +and \field{device_lifetime_est_b} are discussed in the JESD84-B50 specification.
> >
> > -JESD84-B50 is available at the JEDEC website (https://www.jedec.org)
> > -pursuant to JEDEC's licensing terms and conditions.
> > +The complete JESD84-B50 is available at the JEDEC website (https://www.jedec.org)
> > +pursuant to JEDEC's licensing terms and conditions.
>
> These links really belong in either normative or non-normative
> references section.
>
> > For the purposes of this
> > +specification, these fields are defined as follows.
>
> All this seems kind of vague. What does one need that spec for?
> Is it just a note for pass-through developers?
>
> How about "to simplify pass-through
> from eMMC devices the format of fields
> pre_eol_info, device_lifetime_est_typ_a and device_lifetime_est_typ_b
> matches PRE_EOL_INFO, DEVICE_LIFETIME_EST_TYP_A and DEVICE_LIFETIME_EST_TYP_B
> in the
> \hyperref[intro:PCI]{[PCI]}.
>
>
>
> Also, now that I mention it, what about NVMe pass-through? Arguably
> nvme is getting more popular. Will we be able to support that use-case
> as well? Or is more data needed? What is the plan there?
>
> > +
> > +The \field{pre_eol_info} will have one of these values:
Besides specifying the values what does it mean exactly?
E.g. what are blocks?
E.g. "pre_eol_info specifies the percentage of blocks consumed
on the device" and explain what blocks are here.
> > +
> > +\begin{lstlisting}
> > +// Value not available
> > +#define PRE_EOL_INFO_UNDEFINED 0
> > +// < 80% of blocks are consumed
> > +#define PRE_EOL_INFO_NORMAL 1
> > +// 80% of blocks are consumed
> > +#define PRE_EOL_INFO_WARNING 2
> > +// 90% of blocks are consumed
> > +#define PRE_EOL_INFO_URGENT 3
> > +// All others values are reserved
Also please prefix with VIRTIO_BLK_ for consistency.
>
>
> Block comments /* */ should be used as these are documented
> in the introduction.
>
> > +\end{lstlisting}
> > +
> > +The \field{device_lifetime_est_typ_a} refers to wear of SLC cells and is provided in
> > +increments of 10%, with 0 meaning undefined, 1 meaning up-to 10% of lifetime used, and so on,
> > +thru to 11 meaning estimated lifetime exceeded. All values above 11 are reserved.
> > +
> > +The \field{device_lifetime_est_typ_b} refers to wear of MLC cells and is provided with
> > +the same semantics as \field{device_lifetime_est_typ_a}.
> >
> > The final \field{status} byte is written by the device: either
> > VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for device or driver
> > @@ -4812,7 +4831,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> > or UFS persistent storage), the device SHOULD offer the VIRTIO_BLK_F_LIFETIME
> > flag. The flag MUST NOT be offered if the device is backed by storage for which
> > the lifetime metrics described in this document cannot be obtained or for which
> > -such metrics have no useful meaning.
> > +such metrics have no useful meaning. If the metrics are offered, the device MUST NOT
> > +send any reserved values, as defined in this specification.
> >
> > \subsubsection{Legacy Interface: Device Operation}\label{sec:Device Types / Block Device / Device Operation / Legacy Interface: Device Operation}
> > When using the legacy interface, transitional devices and drivers
> > --
> > 2.31.1.368.gbe11c130af-goog
> >
next prev parent reply other threads:[~2021-05-05 10:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 16:25 [PATCH] Provide detailed specification of virtio-blk lifetime metrics Enrico Granata
2021-05-02 9:12 ` Michael S. Tsirkin
2021-05-05 10:34 ` Michael S. Tsirkin [this message]
2021-05-05 19:41 ` Enrico Granata
2021-05-05 5:43 ` Christoph Hellwig
2021-05-05 20:10 ` Michael S. Tsirkin
2021-05-05 21:01 ` [virtio-dev] " Enrico Granata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210505062458-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=egranata@google.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).