[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
again.
> 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.:
guestfs_api_options(EXT_VOL_NAMES, FROBNICATE_SHIZZLES, NULL);
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
types.
> 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.
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
More information about the Libguestfs
mailing list