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.
