qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 00/14] hw/block/nvme: Support Namespace Types and Zoned Na


From: Damien Le Moal
Subject: Re: [PATCH v4 00/14] hw/block/nvme: Support Namespace Types and Zoned Namespace Command Set
Date: Mon, 28 Sep 2020 22:54:46 +0000

On 2020/09/29 6:25, Keith Busch wrote:
> On Mon, Sep 28, 2020 at 08:36:48AM +0200, Klaus Jensen wrote:
>> On Sep 28 02:33, Dmitry Fomichev wrote:
>>> You are making it sound like the entire WDC series relies on this approach.
>>> Actually, the persistency is introduced in the second to last patch in the
>>> series and it only adds a couple of lines of code in the i/o path to mark
>>> zones dirty. This is possible because of using mmap() and I find the way
>>> it is done to be quite elegant, not ugly :)
>>>
>>
>> No, I understand that your implementation works fine without
>> persistance, but persistance is key. That is why my series adds it in
>> the first patch. Without persistence it is just a toy. And the QEMU
>> device is not just an "NVMe-version" of null_blk.
> 
> I really think we should be a bit more cautious of commiting to an
> on-disk format for the persistent state. Both this and Klaus' persistent
> state feels a bit ad-hoc, and with all the other knobs provided, it
> looks too easy to have out-of-sync states, or just not being able to
> boot at all if a qemu versions have different on-disk formats.
> 
> Is anyone really considering zone emulation for production level stuff
> anyway? I can't imagine a real scenario where you'd want put yourself
> through that: you are just giving yourself all the downsides of a zoned
> block device and none of the benefits. AFAIK, this is provided as a
> development vehicle, closer to a "toy".
> 
> I think we should consider trimming this down to a more minimal set that
> we *do* agree on and commit for inclusion ASAP. We can iterate all the
> bells & whistles and flush out the meta data's data marshalling scheme
> for persistence later.

+1 on this. Removing the persistence also removes the debate on endianess. With
that out of the way, it should be straightforward to get agreement on a series
that can be merged quickly to get developers started with testing ZNS software
with QEMU. That is the most important goal here. 5.9 is around the corner, we
need something for people to get started with ZNS quickly.


-- 
Damien Le Moal
Western Digital Research



reply via email to

[Prev in Thread] Current Thread [Next in Thread]