[Libguestfs] Supporting btrfs subvolumes during inspection

Matthew Booth mbooth at redhat.com
Fri Dec 21 09:52:12 UTC 2012

On 20/12/12 19:23, Richard W.M. Jones wrote:
> 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.

They're both ugly. The problem with the new optarg is that you're now 
effectively requiring all future users of the API to add a 'work 
correctly' flag when calling it.

> 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.

I prefer my method, because:

1. Once you concede that the string might not be a device name, you need 
to do string handling on it anyway. A slightly longer string is no 
additional burden.

2. It's sufficiently flexible that we shouldn't get caught out by this 

> 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.

If we're going to be adding flags to things which change the API, I'd 
prefer to do it globally somehow. e.g.:


With each new release, we can then define GUESTFS_2.3.4_OPTS, which 
rolls up everything to date.

This would obviously be only for change which change semantics, but not 

> 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.

Again, given that we're making this change, I wouldn't want to limit us 
to device:subvolume pairs. There's probably something else lurking out 
there, and I wouldn't want to have to add inspect-get-mountpoints3.

It did occur to me that we might return (type, hash) pairs, e.g.:

('btrfs', { device => '/dev/vda4', subvolume => 'root' })

I didn't get as far as reminding myself what hashes look like in the C 
api, though. I also thought of a struct which we could add fields to as 
necessary to accomodate all types, but again I didn't look into what 
which would mean for ABI stability.

> 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?

IIUC, you'll have subvolumes for root, home, opt, etc all on the same 
btrfs filesystem.

Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

More information about the Libguestfs mailing list