All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Alvaro Karsz <alvaro.karsz@solid-run.com>,
	virtualization@lists.linux-foundation.org
Cc: linux-block@vger.kernel.org, dm-devel@redhat.com,
	linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
Date: Mon, 5 Dec 2022 11:24:00 -0700	[thread overview]
Message-ID: <fe2800f1-aaae-33e8-aaf0-83fd034162d5@kernel.dk> (raw)
In-Reply-To: <20221205162035.2261037-1-alvaro.karsz@solid-run.com>

On 12/5/22 9:20 AM, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
> 
> This commit introduces a new ioctl command, VBLK_LIFETIME.
> 
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
> 
> lifetime information fields:
> 
> - pre_eol_info: specifies the percentage of reserved blocks that are
> 		consumed.
> 		optional values following virtio spec:
> 		*) 0 - undefined.
> 		*) 1 - normal, < 80% of reserved blocks are consumed.
> 		*) 2 - warning, 80% of reserved blocks are consumed.
> 		*) 3 - urgent, 90% of reserved blocks are consumed.
> 
> - device_lifetime_est_typ_a: this field refers to wear of SLC cells and
> 			     is provided in increments of 10used, and so
> 			     on, thru to 11 meaning estimated lifetime
> 			     exceeded. All values above 11 are reserved.
> 
> - device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
> 			     provided with the same semantics as
> 			     device_lifetime_est_typ_a.
> 
> The data received from the device will be sent as is to the user.
> No data check/decode is done by virtblk.

Is this based on some spec? Because it looks pretty odd to me. There
can be a pretty wide range of two/three/etc level cells with wildly
different ranges of durability. And there's really not a lot of slc
for generic devices these days, if any.

-- 
Jens Axboe



WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Alvaro Karsz <alvaro.karsz@solid-run.com>,
	virtualization@lists.linux-foundation.org
Cc: linux-scsi@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	dm-devel@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
Date: Mon, 5 Dec 2022 11:24:00 -0700	[thread overview]
Message-ID: <fe2800f1-aaae-33e8-aaf0-83fd034162d5@kernel.dk> (raw)
In-Reply-To: <20221205162035.2261037-1-alvaro.karsz@solid-run.com>

On 12/5/22 9:20 AM, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
> 
> This commit introduces a new ioctl command, VBLK_LIFETIME.
> 
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
> 
> lifetime information fields:
> 
> - pre_eol_info: specifies the percentage of reserved blocks that are
> 		consumed.
> 		optional values following virtio spec:
> 		*) 0 - undefined.
> 		*) 1 - normal, < 80% of reserved blocks are consumed.
> 		*) 2 - warning, 80% of reserved blocks are consumed.
> 		*) 3 - urgent, 90% of reserved blocks are consumed.
> 
> - device_lifetime_est_typ_a: this field refers to wear of SLC cells and
> 			     is provided in increments of 10used, and so
> 			     on, thru to 11 meaning estimated lifetime
> 			     exceeded. All values above 11 are reserved.
> 
> - device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
> 			     provided with the same semantics as
> 			     device_lifetime_est_typ_a.
> 
> The data received from the device will be sent as is to the user.
> No data check/decode is done by virtblk.

Is this based on some spec? Because it looks pretty odd to me. There
can be a pretty wide range of two/three/etc level cells with wildly
different ranges of durability. And there's really not a lot of slc
for generic devices these days, if any.

-- 
Jens Axboe


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Alvaro Karsz <alvaro.karsz@solid-run.com>,
	virtualization@lists.linux-foundation.org
Cc: linux-scsi@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	dm-devel@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [dm-devel] [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support
Date: Mon, 5 Dec 2022 11:24:00 -0700	[thread overview]
Message-ID: <fe2800f1-aaae-33e8-aaf0-83fd034162d5@kernel.dk> (raw)
In-Reply-To: <20221205162035.2261037-1-alvaro.karsz@solid-run.com>

On 12/5/22 9:20 AM, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
> 
> This commit introduces a new ioctl command, VBLK_LIFETIME.
> 
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
> 
> lifetime information fields:
> 
> - pre_eol_info: specifies the percentage of reserved blocks that are
> 		consumed.
> 		optional values following virtio spec:
> 		*) 0 - undefined.
> 		*) 1 - normal, < 80% of reserved blocks are consumed.
> 		*) 2 - warning, 80% of reserved blocks are consumed.
> 		*) 3 - urgent, 90% of reserved blocks are consumed.
> 
> - device_lifetime_est_typ_a: this field refers to wear of SLC cells and
> 			     is provided in increments of 10used, and so
> 			     on, thru to 11 meaning estimated lifetime
> 			     exceeded. All values above 11 are reserved.
> 
> - device_lifetime_est_typ_b: this field refers to wear of MLC cells and is
> 			     provided with the same semantics as
> 			     device_lifetime_est_typ_a.
> 
> The data received from the device will be sent as is to the user.
> No data check/decode is done by virtblk.

Is this based on some spec? Because it looks pretty odd to me. There
can be a pretty wide range of two/three/etc level cells with wildly
different ranges of durability. And there's really not a lot of slc
for generic devices these days, if any.

-- 
Jens Axboe


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

  reply	other threads:[~2022-12-05 18:24 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 16:20 [PATCH v3] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support Alvaro Karsz
2022-12-05 16:20 ` [dm-devel] " Alvaro Karsz
2022-12-05 16:20 ` Alvaro Karsz
2022-12-05 18:24 ` Jens Axboe [this message]
2022-12-05 18:24   ` [dm-devel] " Jens Axboe
2022-12-05 18:24   ` Jens Axboe
2022-12-05 18:36   ` Alvaro Karsz
2022-12-05 18:36     ` [dm-devel] " Alvaro Karsz
2022-12-05 18:36     ` Alvaro Karsz
2022-12-05 18:53     ` Jens Axboe
2022-12-05 18:53       ` [dm-devel] " Jens Axboe
2022-12-05 18:53       ` Jens Axboe
2022-12-05 20:29       ` Michael S. Tsirkin
2022-12-05 20:29         ` [dm-devel] " Michael S. Tsirkin
2022-12-05 20:29         ` Michael S. Tsirkin
2022-12-05 20:35         ` Enrico Granata
2022-12-05 20:35           ` [dm-devel] " Enrico Granata
2022-12-05 23:09           ` Chaitanya Kulkarni
2022-12-05 23:09             ` [dm-devel] " Chaitanya Kulkarni
2022-12-05 20:36         ` Jens Axboe
2022-12-05 20:36           ` [dm-devel] " Jens Axboe
2022-12-05 20:36           ` Jens Axboe
2022-12-05 22:28   ` Chaitanya Kulkarni
2022-12-05 22:28     ` [dm-devel] " Chaitanya Kulkarni
2022-12-05 18:25 ` Jens Axboe
2022-12-05 18:25   ` [dm-devel] " Jens Axboe
2022-12-05 18:25   ` Jens Axboe
2022-12-06 16:31 ` Stefan Hajnoczi
2022-12-06 16:31   ` [dm-devel] " Stefan Hajnoczi
2022-12-06 16:31   ` Stefan Hajnoczi
2022-12-06 16:40   ` Michael S. Tsirkin
2022-12-06 16:40     ` [dm-devel] " Michael S. Tsirkin
2022-12-06 16:40     ` Michael S. Tsirkin
2022-12-06 18:25     ` Alvaro Karsz
2022-12-06 18:25       ` [dm-devel] " Alvaro Karsz
2022-12-06 18:25       ` Alvaro Karsz
2022-12-06 18:43 ` Bart Van Assche
2022-12-06 18:43   ` [dm-devel] " Bart Van Assche
2022-12-06 18:43   ` Bart Van Assche
2022-12-06 19:56   ` Alvaro Karsz
2022-12-06 19:56     ` [dm-devel] " Alvaro Karsz
2022-12-06 19:56     ` Alvaro Karsz
2022-12-07  3:32   ` Chaitanya Kulkarni
2022-12-07  3:32     ` [dm-devel] " Chaitanya Kulkarni
2022-12-07  7:35 ` Christoph Hellwig
2022-12-07  7:35   ` [dm-devel] " Christoph Hellwig
2022-12-07  7:35   ` Christoph Hellwig
2022-12-07 10:21   ` Michael S. Tsirkin
2022-12-07 10:21     ` [dm-devel] " Michael S. Tsirkin
2022-12-07 10:21     ` Michael S. Tsirkin
2022-12-07 16:31     ` Christoph Hellwig
2022-12-07 16:31       ` [dm-devel] " Christoph Hellwig
2022-12-07 16:31       ` Christoph Hellwig
2022-12-07 20:28       ` Michael S. Tsirkin
2022-12-07 20:28         ` [dm-devel] " Michael S. Tsirkin
2022-12-07 20:28         ` Michael S. Tsirkin
2022-12-11  9:49         ` Alvaro Karsz
2022-12-11  9:49           ` [dm-devel] " Alvaro Karsz
2022-12-11  9:49           ` Alvaro Karsz
2022-12-13  4:59           ` Chaitanya Kulkarni
2022-12-13  4:59             ` [dm-devel] " Chaitanya Kulkarni
2022-12-13  4:58         ` Chaitanya Kulkarni
2022-12-13  4:58           ` [dm-devel] " Chaitanya Kulkarni
2022-12-13  6:23           ` Michael S. Tsirkin
2022-12-13  6:23             ` [dm-devel] " Michael S. Tsirkin
2022-12-13  6:23             ` Michael S. Tsirkin
2022-12-19  7:59 ` Michael S. Tsirkin
2022-12-19  7:59   ` Michael S. Tsirkin
2022-12-19  7:59   ` [dm-devel] " Michael S. Tsirkin
2022-12-19  8:39   ` Alvaro Karsz
2022-12-19  8:39     ` [dm-devel] " Alvaro Karsz
2022-12-19  8:39     ` Alvaro Karsz

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=fe2800f1-aaae-33e8-aaf0-83fd034162d5@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=alvaro.karsz@solid-run.com \
    --cc=dm-devel@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stefanha@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.