[Libguestfs] APIs affected by btrfs subvolumes

[Richard W.M. Jones]

On Tue, Jan 22, 2013 at 03:40:16PM +0000, Matthew Booth wrote:
> On Tue, 2013-01-22 at 15:15 +0000, Richard W.M. Jones wrote:
> > Here's my suggestion.
> > 
> > We add a new type 'Mountable' to the generator.  This is the same as a
> > string, so it doesn't change the strict C ABI (nor the semantics --
> > see below).  Certain APIs that take a Device parameter would need to
> > change to take a Mountable instead.
> > 
> > Certain APIs that return RString/RStringList won't change their
> > generator types, but what can be in the string may change.
> > 
> > A Mountable string is normally just a device name, eg. "/dev/sda1".
> > But for special filesystems it may contain an extended string.  I
> > suggest "/dev/sda1:btrfs:<subvolume_name>" for btrfs.  Other weird
> > filesystems may need other extensions in future.
> 
> I'd make 1 change to this. Where a mountable isn't a bare device I'd put
> the device type first as I originally proposed. The reason for this is
> that a mountable doesn't necessarily reference a single block device, or
> indeed any block device (think nfs and iscsi). Also, I'd differentiate
> btrfs and a btrfs subvol. The former can be a bare device, the latter:
> 
> btrfsvol:<device>,<subvolume_name>
> 
> where <device> is any block device which is part of the filesystem.

Sure.  However be careful about subvolume names that contain commas.
Complex escaping rules are something I would very much like to avoid ...

> > Inspection APIs take and return a Mountable (so Device "root" becomes
> > Mountable "root").
> > 
> > 'list-filesystems' returns a list of Mountables (actually it still
> > returns an RStringList, but it's a list of Mountables).
> 
> Hmm. I missed RHashtable in my search. I'd better check for others.
> 
> > 'mount' and friends take a Mountable instead of a Device.
> > 
> > The generator will need to make a small change in the way it checks
> > the Mountable parameter at runtime (q.v. the way Device is checked
> > now, eg. the macro RESOLVE_DEVICE will need another macro
> > RESOLVE_MOUNTABLE).
> > 
> > Obviously the ABI doesn't change, since it's all still strings.  But I
> > also claim that the semantics of the API don't change: Any existing
> > program that works now will continue to work unchanged.  Only programs
> > that would now fail (eg. they try to inspect btrfs guests) would be
> > affected by this change, and in fact those programs would not need to
> > be modified, they would just start to work correctly.
> 
> With the minor tweak above, I like this.
> 
> It does change the semantics slightly, though. Previously, a program
> could assume that something returned by list_filesystems or inspect_os
> was a block device and use it as such, whereas now it can't. However, as
> you point out that was already broken. This change would mean it would
> be broken differently, though. How much do we care about this?
> 
> I'm happy to start hacking on this now,

Shall we dwell on this a bit more?

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://people.redhat.com/~rjones/virt-top