11:24 a.m.
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
1:23 p.m.
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
3:52 a.m.
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
5:20 a.m.
I'd like to think about what calling code would look like. I think
there are two separate issues, which should be treated as separate
things.
(1) guestfs_inspect_os: What to return from inspect_os, given that
multiple roots may exist on a single device.
(2) guestfs_get_filesystems/mountpoints: How to return the list of
devices and mountpoints.
So treating them as separate issues ...
----------------------------------------
(1) guestfs_inspect_os: What to return from inspect_os, given that
multiple roots may exist on a single device.
I think we should treat the "root" strings as opaque. It doesn't
matter (except see below) what we return from inspect_os as long as
the same thing is recognized as a parameter by the other calls.
There is an exception, which is code that I've written for Windows
which assumes root == C: device, ie. it does:
roots = g.inspect_os ();
if #roots > 1 then die;
root = roots[0];
g.mount (root, "/");
To not break the API we really need to keep returning plain device
names for all existing (non-btrfs) OSes.
But since that code would break anyway when presented with a btrfs OS,
we can extend the root string for those. We don't need a flag or a
change to the API types.
----------------------------------------
(2) guestfs_get_filesystems/mountpoints: How to return the list of
devices and mountpoints.
Existing code looks like this:
my @roots = $g->inspect_os ();
for my $root (@roots) {
my %mps = $g->inspect_get_mountpoints ($root);
my @mps = sort { length $a <=> length $b } (keys %mps);
for my $mp (@mps) {
$g->mount_ro ($mps{$mp}, $mp);
# ...
http://libguestfs.org/guestfs-perl.3.html#example-2:-inspect-a-virtual-ma...
If we modify get_mountpoints or even add a new get_mountpoints2 call,
then we push a bunch of complexity up to the user. The mount code has
to look like:
for ($mp, $subvol) (@mps) {
if (!$subvol) {
$g->mount_ro ($mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "btrfs") {
$g->mount_options ("subvol=$subvol", $mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "zfs") {
$g->mount_options ("something=$subvol", $mps{$mp}, $mp);
} else {
die "sorry we don't know how to mount this"
}
}
and that's not very nice.
However changing mount to understand more complex strings containing
subvolumes is also not great, and potentially impacts the whole API
(after all, *any* call which might refer to a filesystem such as
vfs_type, would have to be modified).
So I don't know about (2) yet. Something to keep thinking about.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
5:23 a.m.
On Fri, Dec 21, 2012 at 11:20:44AM +0000, Richard W.M. Jones wrote:
for ($mp, $subvol) (@mps) {
if (!$subvol) {
$g->mount_ro ($mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "btrfs") {
$g->mount_options ("subvol=$subvol", $mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "zfs") {
$g->mount_options ("something=$subvol", $mps{$mp}, $mp);
} else {
die "sorry we don't know how to mount this"
}
}
Hmmm, maybe a subvol => ... parameter to mount?
Also I think vfs_type is a red herring since a subvolume would not
have a separate filesystem type. However there may be other calls
which need to be examined; I can't say without a thorough review.
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
5:53 a.m.
On 21/12/12 11:20, Richard W.M. Jones wrote:
I'd like to think about what calling code would look like. I
think
there are two separate issues, which should be treated as separate
things.
(1) guestfs_inspect_os: What to return from inspect_os, given that
multiple roots may exist on a single device.
(2) guestfs_get_filesystems/mountpoints: How to return the list of
devices and mountpoints.
So treating them as separate issues ...
I don't think these are separate issues, and you provide the example
yourself below.
----------------------------------------
(1) guestfs_inspect_os: What to return from inspect_os, given that
multiple roots may exist on a single device.
I think we should treat the "root" strings as opaque. It doesn't
matter (except see below) what we return from inspect_os as long as
the same thing is recognized as a parameter by the other calls.
There is an exception, which is code that I've written for Windows
which assumes root == C: device, ie. it does:
roots = g.inspect_os ();
if #roots > 1 then die;
root = roots[0];
g.mount (root, "/");
To not break the API we really need to keep returning plain device
names for all existing (non-btrfs) OSes.
This is the example which suggests these are the same issue.
But since that code would break anyway when presented with a btrfs
OS,
we can extend the root string for those. We don't need a flag or a
change to the API types.
----------------------------------------
(2) guestfs_get_filesystems/mountpoints: How to return the list of
devices and mountpoints.
Existing code looks like this:
my @roots = $g->inspect_os ();
for my $root (@roots) {
my %mps = $g->inspect_get_mountpoints ($root);
my @mps = sort { length $a <=> length $b } (keys %mps);
for my $mp (@mps) {
$g->mount_ro ($mps{$mp}, $mp);
# ...
http://libguestfs.org/guestfs-perl.3.html#example-2:-inspect-a-virtual-ma...
If we modify get_mountpoints or even add a new get_mountpoints2 call,
then we push a bunch of complexity up to the user. The mount code has
to look like:
for ($mp, $subvol) (@mps) {
if (!$subvol) {
$g->mount_ro ($mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "btrfs") {
$g->mount_options ("subvol=$subvol", $mps{$mp}, $mp);
} elsif ($g->vfs_type ($mp) eq "zfs") {
$g->mount_options ("something=$subvol", $mps{$mp}, $mp);
} else {
die "sorry we don't know how to mount this"
}
}
and that's not very nice.
However changing mount to understand more complex strings containing
subvolumes is also not great, and potentially impacts the whole API
(after all, *any* call which might refer to a filesystem such as
vfs_type, would have to be modified).
So I don't know about (2) yet. Something to keep thinking about.
Actually, I like the idea of extending mount and anything else which is
similarly impacted. Given that we will be extending the allowed input to
these functions, not their output, this would not be an API break.
I just did a quick run through of APIs which take a Device argument. I
think we could split these into APIs which genuinely take a device, and
those which expect something with a filesystem on it. It could maybe be
called a Mountable. Any API which expects a Mountable would accept the
extended format.
Again, if we're going to make this change I strongly recommend against
assuming that device+subvolume is sufficient. Creating something capable
of handing anything is a trivial extension at this point, but a
potentially large headache later.
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
6:12 a.m.
Can we turn subvolumes into devices somehow using udev? Then they'd
be "/dev/btrfs/sda1/root" and so on, problem solved ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
6:28 a.m.
On 21/12/12 12:12, Richard W.M. Jones wrote:
Can we turn subvolumes into devices somehow using udev? Then they'd
be "/dev/btrfs/sda1/root" and so on, problem solved ...
No, because they're fundamentally not block devices: they're subvolumes
of a 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
4353
days inactive
4354
days old
7 comments
2 participants
participants (2)
-
Matthew Booth -
Richard W.M. Jones