Matthew Booth
2012-Dec-20 17:24 UTC
[Libguestfs] Supporting btrfs subvolumes during inspection
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. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
Richard W.M. Jones
2012-Dec-20 19:23 UTC
[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