Re: [Libguestfs] Supporting btrfs subvolumes during inspection
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:
https://bugzilla.redhat.com/show_bug.cgi?id=824021
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.:
block:/dev/vda2
btrfsvol:/dev/vda4,root
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
string.
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
your proposal.
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?
Rich.
--
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.
http://et.redhat.com/~rjones/virt-top