[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] Supporting btrfs subvolumes during inspection



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]