[Libguestfs] Supporting btrfs subvolumes during inspection
Richard W.M. Jones
rjones at redhat.com
Thu Dec 20 19:23:28 UTC 2012
On Thu, Dec 20, 2012 at 05:24:37PM +0000, Matthew Booth wrote:
> We've currently got a bug in libguestfs which means we can't inspect
> filesystems in btrfs subvolumes:
> This is the default configuration if you select btrfs in F17+. The
> issue is that it requires an api to fix it, as the return values of
> inspect_os, inspect_get_filesystems and inspect_get_mountpoints
> can't express a btrfs subvolume as they're expected to be the names
> of block devices.
> As a starter for 10, I propose the addition of parallel apis
> suffixed _ext which return annotated device descriptions, e.g.:
> The string before the colon is a descriptor. The format of the
> string after the colon is custom to the descriptor, and is described
> in the API. A client program can ignore strings with unknown
> descriptors. New descriptors can be added as required.
> The old apis would return the same as the _ext versions, except they
> would only return block devices. Other devices would be omitted.
Hmm, sounds ugly. We are now allowed to promote non-optargs functions
to optargs functions (as long as you set once_has_no_optargs = true),
so a better way to do what you're proposing would be to add an OBool
flag to the existing APIs.
However .. Could we instead modify inspect_os to return a modified
'root' string (for btrfs subvolumes only) which would be something
like "/dev/vda4:/root" (ie. "device:subvolume"). It depends whether
you consider the root that's returned now to be essentially an opaque
Maybe we could have an OBool flag to turn on this behaviour, and give
an error if the flag is not specified. That's roughly isomorphic to
inspect-get-mountpoints & inspect-get-filesystems also have to be
changed or extended, or we could replace them with inspect-get-*2
variants that can return (device, subvolume) pairs.
This also gets me thinking if there are many other places in the API
where the current device is not sufficient to specify a filesystem
(eg. inspect-list-filesystems? probably not).
Is the Fedora proposal that multiple snapshots will be represented by
separate subvolume names? Or that multiple parallel Fedora installs
will be possible in subvolumes? Or a bit of both?
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
More information about the Libguestfs