Hi Michael,
Sorry, I had no time to create a new version.
I'll do it today.
Alvaro
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, Dec 05, 2022 at 06:20:34PM +0200, 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
> Alvaro could you pls explain the use-case? Christoph has doubts that
> it's useful. Do you have a device implementing this?
Our HW exposes virtio devices, virtio block included.
The block device backend can be a eMMC/uSD card.
The HW can report health values (power, temp, current, voltage) and
On Tue, Dec 13, 2022 at 04:58:47AM +, Chaitanya Kulkarni wrote:
> Michael,
>
> On 12/7/22 12:28, Michael S. Tsirkin wrote:
> > On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> >> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> >>> Christoph you acked
On 12/11/22 01:49, Alvaro Karsz wrote:
>> Alvaro could you pls explain the use-case? Christoph has doubts that
>> it's useful. Do you have a device implementing this?
>
> Our HW exposes virtio devices, virtio block included.
> The block device backend can be a eMMC/uSD card.
>
> The HW can
Michael,
On 12/7/22 12:28, Michael S. Tsirkin wrote:
> On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
>> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
>>> Christoph you acked the spec patch adding this to virtio blk:
>>>
>>> Still not a fan of the
On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> > Christoph you acked the spec patch adding this to virtio blk:
> >
> > Still not a fan of the encoding, but at least it is properly documented
> >
On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> Christoph you acked the spec patch adding this to virtio blk:
>
> Still not a fan of the encoding, but at least it is properly documented
> now:
>
> Acked-by: Christoph Hellwig
>
> Did you change your mind
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
Thanks,
I will fix it in the next version.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Dec 06, 2022 at 11:31:44AM -0500, Stefan Hajnoczi wrote:
> On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
>
> I don't like that the ioctl lifetime struct is passed through
> little-endian from the device to userspace. The point of this new ioctl
> is not to be a passthrough
Hi,
> 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.
Yes, this is based on the virtio spec
On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
I don't like that the ioctl lifetime struct is passed through
little-endian from the device to userspace. The point of this new ioctl
is not to be a passthrough interface. The kernel should define a proper
UABI struct for the ioctl and
Hi Bart,
> Why does the above data structure only refer to SLC and MLC but not to
> TLC or QLC?
This has been discussed before.
The data structure follows the virtio spec
(https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html)
> How will this data structure be extended
The original definitions for these fields come from JESD84-B50, which
is what eMMC storage uses. It has been a while, but I recall UFS doing
something pretty similar.
Systems that don't have a well defined notion of durability would just
not expose the flag (e.g. a spinning disk), and going for
On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
> On 12/5/22 11:36 AM, Alvaro Karsz wrote:
> > Hi,
> >
> >> 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
On Tue, Dec 06, 2022 at 11:35:31PM -0800, Christoph Hellwig wrote:
> This just seems like a horrible interface. And virtio-blk should be
> a simple passthrough and not grow tons of side-band crap like this.
>
> If you want to pass through random misc information use virtio-scsi
> or nvme with
This just seems like a horrible interface. And virtio-blk should be
a simple passthrough and not grow tons of side-band crap like this.
If you want to pass through random misc information use virtio-scsi
or nvme with shadow doorbell buffers.
--
dm-devel mailing list
dm-devel@redhat.com
Bart,
On 12/6/22 10:43, Bart Van Assche wrote:
> On 12/5/22 08:20, Alvaro Karsz wrote:
>> +/* Get lifetime information struct for each request */
>> +struct virtio_blk_lifetime {
>> + /*
>> + * specifies the percentage of reserved blocks that are consumed.
>> + * optional values
On 12/5/22 08:20, Alvaro Karsz wrote:
+/* Get lifetime information struct for each request */
+struct virtio_blk_lifetime {
+ /*
+* specifies the percentage of reserved blocks that are consumed.
+* optional values following virtio spec:
+* 0 - undefined
+* 1
On 12/5/22 12:35, Enrico Granata wrote:
> The original definitions for these fields come from JESD84-B50, which
> is what eMMC storage uses. It has been a while, but I recall UFS doing
> something pretty similar.
> Systems that don't have a well defined notion of durability would just
> not expose
On 12/5/22 10:24, Jens Axboe wrote:
> 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
>>
On 12/5/22 1:29?PM, Michael S. Tsirkin wrote:
> On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
>> On 12/5/22 11:36?AM, Alvaro Karsz wrote:
>>> Hi,
>>>
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
On 12/5/22 11:36 AM, Alvaro Karsz wrote:
> Hi,
>
>> 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,
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
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
26 matches
Mail list logo
