Re: [dm-devel] [PATCH 0/4] dm: Introduce dm-qcow2 driver to attach QCOW2 files as block device

[Christoph Hellwig <hch@infradead.org>]

On Mon, Mar 28, 2022 at 02:18:16PM +0300, Kirill Tkhai wrote:
> This patchset adds a new driver allowing to attach QCOW2 files
> as block devices. Its idea is to implement in kernel only that
> features, which affect runtime IO performance (IO requests
> processing functionality).

From a quick looks it seems to be like this should be a block driver
just like the loop driver and not use device mapper.  Why would
you use device mapper to basically reimplement a fancy loop driver
to start with?

> The maintenance operations are
> synchronously processed in userspace, while device is suspended.
> 
> Userspace is allowed to do only that operations, which never
> modifies virtual disk's data. It is only allowed to modify
> QCOW2 file metadata providing that disk's data. The examples
> of allowed operations is snapshot creation and resize.

And this sounds like a pretty fragile design.  It basically requires
both userspace and the kernel driver to access metadata on disk, which
sounds rather dangerous.

> This example shows the way of device-mapper infrastructure
> allows to implement drivers following the idea of
> kernel/userspace components demarcation. Thus, the driver
> uses advantages of device-mapper instead of implementing
> its own suspend/resume engine.

What do you need more than a queue freeze?