Andre Przywara wrote:
Laurent Vivier wrote:
What I'm wondering is how loop and device mapper can work ?
I shortly evaluated the loop device idea, but came to the conclusion
that this not so easy to implement (and would require qcow code in the
kernel). I see only little chance for this go upstream in Linux and
maintaining this out-of-tree is actually a bad idea.
I recently was poking around at the loop device and discovered that it
had a plugging xfer ops to allow for encrypted loop devices. My initial
analysis was that by simply adding a couple of operations to that
structure (such as map_sector and get_size), you could very easily write
a kernel module that registered a set of xfer ops that implemented QCOW
support.
Of course, this would all be kernel code. The best solution would be a
proper userspace block device. I think it's a pretty reasonable
stop-gap though (that wouldn't be very difficult to get merged upstream).
If you think about deferring the qcow code into userland, you will
sooner or later run into the same deadlock problems as the current
solution (after all this is what nbd does...)
I have implemented a clean device-mapper solution, the big drawback is
that it is read-only. It's a simple tool which converts the qcow map
into a format suitable for dm-setup, to which the output can be
directly piped to. I will clean up the code and send it to the list ASAP.
You could only do something read-only with device mapper. dm-userspace
was an effort to try and work around that with a userspace daemon but it
didn't move upstream as quickly as we would have liked.
Regards,
Anthony Liguori
Read/write support is not that easy, but maybe someone can comment on
this idea:
Create a sparse file on the host which is as large as the number of
all still unallocated blocks. Assign these blocks via device mapper in
addition to the already allocated ones. When unmounting the dm device,
look for blocks which have been changed and allocate and write them
into the qcow file. One could also use the bmap-ioctl to scan for
non-sparse blocks.
This is a bit complicated, but should work cleanly (especially for the
quick fsck or file editing case). If you find it worth, I could try to
implement it.
Regards,
Andre.