Make it possible to mount image files.

Such a mechanism is on my todo list already.

AFAIK fuse is not a appropriate solution here because we need to present an image file as a regular block
device and then let the 'mount' utility deal with it. Fuse is about implementing a filesystem interface not
a block device interface.

Device mapper fits the problem better. Xen devs implemented a new device mapper target - dm-userspace
http://wiki.xensource.com/xenwiki/DmUserspace

That is exactly what we need. Using dm-userspace and cowd we could implement a cowd plugin for mapping
requests according to the partimage-ng image file format. Sounds easy enough.

2008/3/15, Dmitry Ivanov <email address hidden>:
> Such a mechanism is on my todo list already.
>
> AFAIK fuse is not a appropriate solution here because we need to present an image file as a regular block
> device and then let the 'mount' utility deal with it. Fuse is about implementing a filesystem interface not
> a block device interface.
>
> Device mapper fits the problem better. Xen devs implemented a new device mapper target - dm-userspace
> http://wiki.xensource.com/xenwiki/DmUserspace
>
> That is exactly what we need. Using dm-userspace and cowd we could implement a cowd plugin for mapping
> requests according to the partimage-ng image file format. Sounds easy enough.

Never heard of dm-userspace and cowd before.
I'll trust you, when you say, that fuse is probably not the right
approach (I was simply proposing it, because ntfsclone/ntfsmount uses
it and it seems to work for them).
What are the requirements for dm-userpace/cowd?
Does that require a kernel patch? Does any distribution already ship
the dm-userspace/cowd tools? At least Debian/Ubuntu doesn't seem to.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

dm-userspace is a kernel module (there is a kernel patch against 2.6.20), cowd is a user-space utility.
But its development seems to be suspended. The latest patch is against the kernel that was released in February, 2007.
The latest update in the mercurial repo is dated March, 2007.
I grepped the xen source code and found out that they are using blktap now instead of dm-userspace.
We could utilize blktap but that would require to install xen-related packages.

Anyway, device-mapper is the right framework for mounting partimage-ng's image files. I'll write a new device-mapper target
that simply maps i/o requests to an image file associated with a loop device (using losetup).

A couple of things to keep in mind, as I've been thinking of doing something similar with qcow images.

partimage-ng is not the only image type people want to mount, so please at least think about something a bit more generic, like dm-userspace. blktap is a non-starter is it relies on xen-specific kernel patches (plus, judging from the almost-but-not-quite-compatible-with-real-qcow-files implementation of thier qcow blktap device, I'm not convinced their code is a good starting place. Go ahead, create a qcow file using qemu's 'qemu-img' utility and then try to mount it under blktap, it won't work because they only support qcow files that are super aligned.. I lost 2 weeks of my life chasing that one down.)

Also, consider using a NBD over loopback, and implement an nbd server which talks to your image file as a backend. AnthonyL has already done this for qcow images as part of his work with KVM. The advantage of this is that an NBD server is done completely in userspace. The disadvantage is that I'm not getting his stuff to work reliably ;)

However, all of these things suffer from one fundamental problem (dm-userspace as well I think).. there's a potential deadlock in low memory situations on single CPU systems. i.e., If you mount a filesystem from an image that's on another filesystem, the kernel treats them as separate block devices even though they're really one device. If you have a low memory situation, then the kernel might decide to start flushing buffers to each 'block device'.. the flushing of both devices can get in each others way. On an SMP system, there are multiple flush threads, so one thread blocking can't hold up the other.. but on a single CPU system, there's only one thread, and a potential deadlock. the NBD page has a better writeup about this.

I heard a rumor there's a patch out for 2.6.26+ that created a new thread for flushing to nbd devices to avoid this problem, but I haven't seen it. I don't know if DM has this problem or not, but you may want to keep this in the back of your head as you go forward. In fact, you may want to talk to the KVM folks, as virtualization people face this problem all the time.

The more I ponder the idea with nbd, the more I think it would be the right direction.

Actually I would go one step further and propose a new design for partimage-ng (partimage-nng?):
1. Make partimage-nng a simple, dd-style program that works like dd in every respect with the exception of understanding the underlying filesystem and thus skipping over unused areas using lseek (on both sides).
2. Put the image file format logic in an nbd-server.

This has several nice features:
1. Such a partimage-nng could also be used to quickly clone real disks.
2. It can also be used to make sparse-file-style images.
3. It's a KISS and "small tool for small tasks" approach
4. It becomes trivial to support mounting of partimage-ng imagefiles
5. The imagefile format logic is nicely capsuled into the nbd-server.
    This also allows for easy conversion between formats and usage of formats from other systems that have similar properties like the image files of emulation/virtualization packages.
    Simply start two servers that are set for the formats you like and use partimage-nng to copy between them.
6. Allow for incremental backup etc. by using smart CoW-capable nbd-server backends that detect if
a write has actually changed data.

It has a few drawbacks, though, that could be alleviated by adding a few extensions to the nbd-server:
- No support for cloning/restoring parts of whole disks like individual partitions.
- nbd-server is currently not suited to _create_ the target image
- network transport is often a bottleneck, so it might be wise to compress it.
- for CoW stuff it would be useful to be able to check if a remote block is already the same as the local one by e.g. comparing hashes, which allows to keep network traffic very low if the image has not changed much since the last backup (a la rsync).

So: Does anyone like this design idea?