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? -- dm-devel mailing list [email protected] https://listman.redhat.com/mailman/listinfo/dm-devel
