[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YkME5ZS2CpXuNmN6@infradead.org>
Date: Tue, 29 Mar 2022 06:08:53 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Kirill Tkhai <kirill.tkhai@...nvz.org>
Cc: agk@...hat.com, snitzer@...hat.com, dm-devel@...hat.com,
song@...nel.org, linux-kernel@...r.kernel.org,
khorenko@...tuozzo.com
Subject: Re: [dm-devel] [PATCH 0/4] dm: Introduce dm-qcow2 driver to attach
QCOW2 files as block device
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?
Powered by blists - more mailing lists