On 29.03.2010, at 11:37, Jan Kiszka wrote: > Alexander Graf wrote: >> On 29.03.2010, at 09:46, Jan Kiszka wrote: >> >>> Christoph Hellwig wrote: >>>> On Thu, Mar 25, 2010 at 06:52:59PM +0100, Jan Kiszka wrote: >>>>> This adds the "map" subcommand to qemu-img. It is able to expose the raw >>>>> content of a disk image via a FUSE filesystem. Both the whole disk can >>>>> be accessed, e.g. to run partitioning tools against it, as well as >>>>> individual partitions. This allows to create new filesystems in the >>>>> image or loop-back mount exiting ones. Using the great mountlo tool >>>>> from the FUSE collection [1][2], the latter can even be done by non-root >>>>> users (the former anyway). >>>> Is there a good reason to throw this into qemu-img instead of making >>>> a separate qemu-fuse or similar tool? It's doing something quite >>>> different than the rest of qemu-img. >>>> >>> qemu-img is the swiss knife for QEMU disk image manipulation (like git >>> is for everything around a git repository). So, IHMO, mapping the image >>> content into the host filesystem for further manipulation with standard >>> tools belongs to this. >>> >>> If the "map" thing works out for most users, I could even imagine some >>> helper sub-command "mount" that encapsulates map and mountlo (or some >>> other unprivileged mounting mechanism). This should make it easier for >>> users to explore all possibilities they have when working with disk images. >> >> We also have a tool called "qemu-ext2" lying around that allows you to >> explore ext2 based file system contents in any qemu block layer supported >> backend. > > "we" == SUSE?
"we" == "SUSE Studio" (in fact, Nat wrote it). It is GPL'ed, just not released yet. As soon as there will be a separate project with a broader scope than just qemu for the block layer, I'll happily invest the time to clean it up for upstream submission. Alex
