Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/07/2014 07:26 PM, Lennart Poettering wrote:
> Heya!
> 
> Since yesterday systemd in git can now discover root, /home, /srv and
> swap partitions automatically based on GPT type GUIDs, thus making
> /etc/fstab unnecessary for simple setups.
> 
> I have now put together something like a spec describing the logic
> behind that, and what it is good for:

> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> 

Form the FAQ:
<CITE>
[...] What about automatic mounting of btrfs subvolumes to /var, /home and so on?

Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible. [...]
</CITE>

Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.

For example supposing to use '@' as prefix for a subvolume name:

@ 	-> root filesystem
@etc	-> etc
@home 	-> home
[...]

If you want multiple OS on the same filesystem we can use the following convention

@home		-> home of all the systems
@srv		-> srv  of all the systems
@fedora_	-> root of a fedora system
@fedora_etc	-> etc of the fedora system
@fedora2_	-> root of a fedora2 system
@fedora2_etc	-> etc of the fedora2 system

Or in another way we could group the different systems in subdirectories:

@home		-> home of all the systems
@srv		-> srv  of all the systems
fedora/@	-> root of a fedora system
fedora/@etc	-> etc of the fedora system
fedora2/@	-> root of a fedora2 system
fedora2/@etc	-> etc of the fedora2 system



-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Kay Sievers]

On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli <kreijack@libero.it> wrote:
> On 03/07/2014 07:26 PM, Lennart Poettering wrote:

>> Since yesterday systemd in git can now discover root, /home, /srv and
>> swap partitions automatically based on GPT type GUIDs, thus making
>> /etc/fstab unnecessary for simple setups.
>>
>> I have now put together something like a spec describing the logic
>> behind that, and what it is good for:
>
>> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
>>
>
> Form the FAQ:
> <CITE>
> [...] What about automatic mounting of btrfs subvolumes to /var, /home and so on?
>
> Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible. [...]
> </CITE>
>
> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.

As a general rule: human-readable names should be left to the
administrator, provide an identifier for humans, and should not be
overloaded with magic machine behavior.

Kay

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

Hi Kay
On 03/10/2014 07:53 PM, Kay Sievers wrote:
[...]
>>
>> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.
> 
> As a general rule: human-readable names should be left to the
> administrator, provide an identifier for humans, and should not be
> overloaded with magic machine behavior.

In general I agree with you. 
But using "a name" you can manage multiple system on the same filesystem. This is impossible with the UUID.

> 
> KayGoffredo-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Murphy]

On Mar 10, 2014, at 12:34 PM, Goffredo Baroncelli <kreijack@libero.it> wrote:

> On 03/07/2014 07:26 PM, Lennart Poettering wrote:
>> Heya!
>> 
>> Since yesterday systemd in git can now discover root, /home, /srv and
>> swap partitions automatically based on GPT type GUIDs, thus making
>> /etc/fstab unnecessary for simple setups.
>> 
>> I have now put together something like a spec describing the logic
>> behind that, and what it is good for:
> 
>> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
>> 
> 
> Form the FAQ:
> <CITE>
> [...] What about automatic mounting of btrfs subvolumes to /var, /home and so on?
> 
> Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible. [...]
> </CITE>
> 
> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.


We have a problem the instant the user snapshots any subvolume being mounted in this fashion. The resulting snapshot presumably would inherit the same "subvolumetypeGUID" as the parent, and it's now ambiguous which should be automounted, or how to fail.



Chris Murphy

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreijack@libero.it) wrote:

Heya,

> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.
> 
> For example supposing to use '@' as prefix for a subvolume name:
> 
> @ 	-> root filesystem
> @etc	-> etc
> @home 	-> home
> [...]

Well, the name is property of the admin really. There needs to be a way
how the admin can label his subvolumes, with a potentially localized
name. This makes it unsuitable for our purpose, we cannot just take
possession of this and leave the admin with nothing.

On GPT there are also gpt partition labels and partition types. The
former are property of the admin, he can place there whatever he wants,
in whatever language he chooses... The latter however is how we make
sense of it on a semantical level.

> Or in another way we could group the different systems in subdirectories:
> 
> @home		-> home of all the systems
> @srv		-> srv  of all the systems
> fedora/@	-> root of a fedora system
> fedora/@etc	-> etc of the fedora system
> fedora2/@	-> root of a fedora2 system
> fedora2/@etc	-> etc of the fedora2 system

I am pretty sure automatic discovery of mount points should not cover
the usecase where people install multiple distributions into the same
btrfs volume. THe automatic logic should cover the simple cases only,
and it sounds way over the top to support installing multiple OSes into
the same btrfs... I mean, people can do that, if they want to, they just
have to write a proper fstab, which I think is not too much too ask...

Lennart

-- 
Lennart Poettering, Red Hat

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Mason]

On 03/10/2014 04:02 PM, Lennart Poettering wrote:
> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreijack@libero.it) wrote:
>
> Heya,
>
>> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.
>>
>> For example supposing to use '@' as prefix for a subvolume name:
>>
>> @ 	-> root filesystem
>> @etc	-> etc
>> @home 	-> home
>> [...]
>
> Well, the name is property of the admin really. There needs to be a way
> how the admin can label his subvolumes, with a potentially localized
> name. This makes it unsuitable for our purpose, we cannot just take
> possession of this and leave the admin with nothing.
>
> On GPT there are also gpt partition labels and partition types. The
> former are property of the admin, he can place there whatever he wants,
> in whatever language he chooses... The latter however is how we make
> sense of it on a semantical level.
>
>> Or in another way we could group the different systems in subdirectories:
>>
>> @home		-> home of all the systems
>> @srv		-> srv  of all the systems
>> fedora/@	-> root of a fedora system
>> fedora/@etc	-> etc of the fedora system
>> fedora2/@	-> root of a fedora2 system
>> fedora2/@etc	-> etc of the fedora2 system
>
> I am pretty sure automatic discovery of mount points should not cover
> the usecase where people install multiple distributions into the same
> btrfs volume. THe automatic logic should cover the simple cases only,
> and it sounds way over the top to support installing multiple OSes into
> the same btrfs... I mean, people can do that, if they want to, they just
> have to write a proper fstab, which I think is not too much too ask...

Thinking more about this, using the UUIDs does make it harder for the 
admin to roll back and forth between snapshots.  This is similar to the 
multiple install idea, but the goal would be easily jumping back to the 
old one if an update failed.

I'm not against anything that makes us more flexible here, just trying 
to nail down the use case a little bit more.

-chris

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Murphy]

On Mar 10, 2014, at 2:21 PM, Chris Mason <clm@fb.com> wrote:

> On 03/10/2014 04:02 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreijack@libero.it) wrote:
>> 
>> Heya,
>> 
>>> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.
>>> 
>>> For example supposing to use '@' as prefix for a subvolume name:
>>> 
>>> @ 	-> root filesystem
>>> @etc	-> etc
>>> @home 	-> home
>>> [...]
>> 
>> Well, the name is property of the admin really. There needs to be a way
>> how the admin can label his subvolumes, with a potentially localized
>> name. This makes it unsuitable for our purpose, we cannot just take
>> possession of this and leave the admin with nothing.
>> 
>> On GPT there are also gpt partition labels and partition types. The
>> former are property of the admin, he can place there whatever he wants,
>> in whatever language he chooses... The latter however is how we make
>> sense of it on a semantical level.
>> 
>>> Or in another way we could group the different systems in subdirectories:
>>> 
>>> @home		-> home of all the systems
>>> @srv		-> srv  of all the systems
>>> fedora/@	-> root of a fedora system
>>> fedora/@etc	-> etc of the fedora system
>>> fedora2/@	-> root of a fedora2 system
>>> fedora2/@etc	-> etc of the fedora2 system
>> 
>> I am pretty sure automatic discovery of mount points should not cover
>> the usecase where people install multiple distributions into the same
>> btrfs volume. THe automatic logic should cover the simple cases only,
>> and it sounds way over the top to support installing multiple OSes into
>> the same btrfs... I mean, people can do that, if they want to, they just
>> have to write a proper fstab, which I think is not too much too ask...
> 
> Thinking more about this, using the UUIDs does make it harder for the admin to roll back and forth between snapshots.  This is similar to the multiple install idea, but the goal would be easily jumping back to the old one if an update failed.

Since it's not a given whether a parent or child subvolume is the one being updated, it's ambiguous which one to use/automount if there is inheritance of the proposed subvolumetypeGUID at snapshot time. Inheritance of the proposed GUID at snapshot time sounds untenable.

Failsafe for rootfs is to snapshot, mount it, apply updates to the snapshot in a chroot. That way a failed update means the snapshot can be immediately deleted. And the OS is overall more stable by not having running binaries modified or yanked out from under it. Here, using the current subvolume at reboot is the rollback; changing to the snapshot is the upgrade.

Whereas for home, rebooting to the snapshot is a rollback, which I certainly don't want by default.

I don't see the right way to handle this automatically or by default.

> I'm not against anything that makes us more flexible here, just trying to nail down the use case a little bit more.

Faster mounts, before the fstab would otherwise be read and parsed? OS X has deprecated fstab entirely in favor of autodiscovery/automounting. The /etc/fstab is no longer present (but is honored if created).


Chris Murphy

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 14:53, Chris Murphy (lists@colorremedies.com) wrote:

> Since it's not a given whether a parent or child subvolume is the one
> being updated, it's ambiguous which one to use/automount if there is
> inheritance of the proposed subvolumetypeGUID at snapshot
> time. Inheritance of the proposed GUID at snapshot time sounds
> untenable.
> 
> Failsafe for rootfs is to snapshot, mount it, apply updates to the
> snapshot in a chroot. That way a failed update means the snapshot can
> be immediately deleted. And the OS is overall more stable by not
> having running binaries modified or yanked out from under it. Here,
> using the current subvolume at reboot is the rollback; changing to the
> snapshot is the upgrade.
> 
> Whereas for home, rebooting to the snapshot is a rollback, which I
> certainly don't want by default.
> 
> I don't see the right way to handle this automatically or by default.

I am in no way bound to the idea of having subvolume type UUIDs for
this. There are other options. For example, there's already the concept
of having "default" subvolumes ("btrfs subvolume set-default"...), maybe
we can extend that a little bit, and allow different kinds of default
subvolumes, one "default /home subvolume", one "default /srv subvolume",
and so on, plus one "default root subvolume", and so on. The vocabulary
for the available "default" subvolumes could be a free-form string where
the empty string would be the existing default subvolume. Or so...

When people play games with subvolumes and snapshots we could then
simply ask them to update where these "default" subvolumes point... Of
course this simply exports to the admin the problem of combining
subvolumes properly.

Another option would be to introduce a high level concept of a
"subvolume set" or so, which binds subvolumes together, and of which
there could be a "default subvolume set". Within such a subvolume set
could then use type uuids or so to mount things properly. Or something
like that...

Lennart

-- 
Lennart Poettering, Red Hat

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/10/2014 09:02 PM, Lennart Poettering wrote:
> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreijack@libero.it) wrote:
> 
> Heya,
> 
>> Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them.
>>
>> For example supposing to use '@' as prefix for a subvolume name:
>>
>> @ 	-> root filesystem
>> @etc	-> etc
>> @home 	-> home
>> [...]
> 
> Well, the name is property of the admin really. There needs to be a way
> how the admin can label his subvolumes, with a potentially localized
> name. This makes it unsuitable for our purpose, we cannot just take
> possession of this and leave the admin with nothing.

Instead of the name we can use the xattr to store these information.


> On GPT there are also gpt partition labels and partition types. The
> former are property of the admin, he can place there whatever he wants,
> in whatever language he chooses... The latter however is how we make
> sense of it on a semantical level.
> 
>> Or in another way we could group the different systems in subdirectories:
>>
>> @home		-> home of all the systems
>> @srv		-> srv  of all the systems
>> fedora/@	-> root of a fedora system
>> fedora/@etc	-> etc of the fedora system
>> fedora2/@	-> root of a fedora2 system
>> fedora2/@etc	-> etc of the fedora2 system
> 
> I am pretty sure automatic discovery of mount points should not cover
> the usecase where people install multiple distributions into the same
> btrfs volume. THe automatic logic should cover the simple cases only,
> and it sounds way over the top to support installing multiple OSes into
> the same btrfs... I mean, people can do that, if they want to, they just
> have to write a proper fstab, which I think is not too much too ask...

In your specification, you referred the use case of "container" (via nspawn / libvrt-lxc). which have to boot "a disk image". Why you don't mind to use a container on a btrfs snapshot ? I think that it will be reasonable to have different containers on a snapshots of the same filesystem-tree.


> 
> Lennart
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/10/2014 09:21 PM, Chris Mason wrote:
> On 03/10/2014 04:02 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreijack@libero.it) wrote:
[...]
>> I am pretty sure automatic discovery of mount points should not cover
>> the usecase where people install multiple distributions into the same
>> btrfs volume. THe automatic logic should cover the simple cases only,
>> and it sounds way over the top to support installing multiple OSes into
>> the same btrfs... I mean, people can do that, if they want to, they just
>> have to write a proper fstab, which I think is not too much too ask...
> 
> Thinking more about this, using the UUIDs does make it harder for the
> admin to roll back and forth between snapshots. This is similar to
> the multiple install idea, but the goal would be easily jumping back
> to the old one if an update failed.
> 
> I'm not against anything that makes us more flexible here, just
> trying to nail down the use case a little bit more.>

We can store the mount point in a xattr. Also we can store the snapshots relation (parent/child or real/rollback) in a xattr. During the boot a "systemd-btrfs-fstab-generator" could generate on the fly the right mounts list.



 
> -chris
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:

> > Well, the name is property of the admin really. There needs to be a way
> > how the admin can label his subvolumes, with a potentially localized
> > name. This makes it unsuitable for our purpose, we cannot just take
> > possession of this and leave the admin with nothing.
> 
> Instead of the name we can use the xattr to store these information.

Ah, using xattrs for this is indeed an option. That way we should be able
attach any kind of information we like to a subvolume.

Hmm, I figure though that there is no way currently to read xattrs off a
subvolume without first mounting them individually? Having to mount all
subvolumes before we can make sense of them and mount them to the right
place certainly sounds less than ideal...

> > On GPT there are also gpt partition labels and partition types. The
> > former are property of the admin, he can place there whatever he wants,
> > in whatever language he chooses... The latter however is how we make
> > sense of it on a semantical level.
> > 
> >> Or in another way we could group the different systems in subdirectories:
> >>
> >> @home		-> home of all the systems
> >> @srv		-> srv  of all the systems
> >> fedora/@	-> root of a fedora system
> >> fedora/@etc	-> etc of the fedora system
> >> fedora2/@	-> root of a fedora2 system
> >> fedora2/@etc	-> etc of the fedora2 system
> > 
> > I am pretty sure automatic discovery of mount points should not cover
> > the usecase where people install multiple distributions into the same
> > btrfs volume. THe automatic logic should cover the simple cases only,
> > and it sounds way over the top to support installing multiple OSes into
> > the same btrfs... I mean, people can do that, if they want to, they just
> > have to write a proper fstab, which I think is not too much too ask...
> 
> In your specification, you referred the use case of "container" (via
> nspawn / libvrt-lxc). which have to boot "a disk image". Why you don't
> mind to use a container on a btrfs snapshot ? I think that it will be
> reasonable to have different containers on a snapshots of the same
> filesystem-tree.

Hmm, dunno, you might have a point there...

Lennart

-- 
Lennart Poettering, Red Hat

Re: [HEADS-UP] Discoverable Partitions Spec

[Alex Elsayed]

Lennart Poettering wrote:

> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
> 
>> > Well, the name is property of the admin really. There needs to be a way
>> > how the admin can label his subvolumes, with a potentially localized
>> > name. This makes it unsuitable for our purpose, we cannot just take
>> > possession of this and leave the admin with nothing.
>> 
>> Instead of the name we can use the xattr to store these information.
> 
> Ah, using xattrs for this is indeed an option. That way we should be able
> attach any kind of information we like to a subvolume.
> 
> Hmm, I figure though that there is no way currently to read xattrs off a
> subvolume without first mounting them individually? Having to mount all
> subvolumes before we can make sense of them and mount them to the right
> place certainly sounds less than ideal...

Well, you can always mount subvol=. aka subvolid=0 - the 'root subvolume' 
since they are strictly hierarchical. 'btrfs subvolume list' can then give 
you every subvol in the FS.

>> > On GPT there are also gpt partition labels and partition types. The
>> > former are property of the admin, he can place there whatever he wants,
>> > in whatever language he chooses... The latter however is how we make
>> > sense of it on a semantical level.
>> > 
>> >> Or in another way we could group the different systems in
>> >> subdirectories:
>> >>
>> >> @home		-> home of all the systems
>> >> @srv		-> srv  of all the systems
>> >> fedora/@	-> root of a fedora system
>> >> fedora/@etc	-> etc of the fedora system
>> >> fedora2/@	-> root of a fedora2 system
>> >> fedora2/@etc	-> etc of the fedora2 system
>> > 
>> > I am pretty sure automatic discovery of mount points should not cover
>> > the usecase where people install multiple distributions into the same
>> > btrfs volume. THe automatic logic should cover the simple cases only,
>> > and it sounds way over the top to support installing multiple OSes into
>> > the same btrfs... I mean, people can do that, if they want to, they
>> > just have to write a proper fstab, which I think is not too much too
>> > ask...
>> 
>> In your specification, you referred the use case of "container" (via
>> nspawn / libvrt-lxc). which have to boot "a disk image". Why you don't
>> mind to use a container on a btrfs snapshot ? I think that it will be
>> reasonable to have different containers on a snapshots of the same
>> filesystem-tree.
> 
> Hmm, dunno, you might have a point there...

I can confirm that I _currently_ do btrfs-subvol based containers with 
libvirt-lxc and it's quite useful... and in terms of on-disk hierarchy, each 
machine is a subvol at the toplevel in subvolid=0. Equal to the host.

i.e.:
subvol=.
  virt-host
  postgres
  powerdns
  ...etc...

Where postgres and powerdns are LXC container filesystems.

> Lennart
> 

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Calvin Walton]

On Tue, 2014-03-11 at 00:45 +0100, Lennart Poettering wrote:
> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
> 
> > > Well, the name is property of the admin really. There needs to be a way
> > > how the admin can label his subvolumes, with a potentially localized
> > > name. This makes it unsuitable for our purpose, we cannot just take
> > > possession of this and leave the admin with nothing.
> > 
> > Instead of the name we can use the xattr to store these information.
> 
> Ah, using xattrs for this is indeed an option. That way we should be able
> attach any kind of information we like to a subvolume.
> 
> Hmm, I figure though that there is no way currently to read xattrs off a
> subvolume without first mounting them individually? Having to mount all
> subvolumes before we can make sense of them and mount them to the right
> place certainly sounds less than ideal...

One thing to remember about the way btrfs snapshots/subvolumes work is
that they simply show up as directories within the filesystem tree.
There is no separate namespace for storing subvolumes; they all end up
in a single unified filesystem tree along with regular files and
directories.

As a result, you can simply mount the root of the filesystem, and then
read xattrs off any and all of the subvolumes.

In fact, mounting a the subvolume "/@home" to "/home" in btrfs is
effectively equivalent to

mount -t btrfs -o subvolid=0 /dev/sda1 /home
mount --bind /home/@home /home

except done as a single step in one mount command.

-- 
Calvin Walton <calvin.walton@kepstin.ca>

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Mason]

On 03/10/2014 07:45 PM, Lennart Poettering wrote:
> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
>
>>> Well, the name is property of the admin really. There needs to be a way
>>> how the admin can label his subvolumes, with a potentially localized
>>> name. This makes it unsuitable for our purpose, we cannot just take
>>> possession of this and leave the admin with nothing.
>>
>> Instead of the name we can use the xattr to store these information.
>
> Ah, using xattrs for this is indeed an option. That way we should be able
> attach any kind of information we like to a subvolume.
>
> Hmm, I figure though that there is no way currently to read xattrs off a
> subvolume without first mounting them individually? Having to mount all
> subvolumes before we can make sense of them and mount them to the right
> place certainly sounds less than ideal...

Ok, are we hoping to pull the xattrs off the disk before mounting 
anything?  Or can we do a mount in a side directory first to scan for 
subvols?

I like the idea of something like this:

mount device on /search_for_fstab
cd /search_for_fstab/<some_magic_directory_name_option_in_systemd>

read xattrs on directories it finds to see where they should be mounted 
in the FS.  xattrs may include mount options and special flags.

mount the things you find

umount /search_for_fstab

I like that it's not actually btrfs specific, since the bind mounts will 
work for any FS.  But it naturally fits the /@ namespace that we seem to 
be favoring as a collection point for snapshots and subvolumes.

-chris

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/12/2014 06:24 PM, Chris Mason wrote:
> 
> 
> On 03/10/2014 07:45 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
>>
>>>> Well, the name is property of the admin really. There needs to be a way
>>>> how the admin can label his subvolumes, with a potentially localized
>>>> name. This makes it unsuitable for our purpose, we cannot just take
>>>> possession of this and leave the admin with nothing.
>>>
>>> Instead of the name we can use the xattr to store these information.
>>
>> Ah, using xattrs for this is indeed an option. That way we should be able
>> attach any kind of information we like to a subvolume.
>>
>> Hmm, I figure though that there is no way currently to read xattrs off a
>> subvolume without first mounting them individually? Having to mount all
>> subvolumes before we can make sense of them and mount them to the right
>> place certainly sounds less than ideal...
> 
> Ok, are we hoping to pull the xattrs off the disk before mounting
> anything? Or can we do a mount in a side directory first to scan for
> subvols?
> 
> I like the idea of something like this:
> 
> mount device on /search_for_fstab cd
> /search_for_fstab/<some_magic_directory_name_option_in_systemd>
> 
> read xattrs on directories it finds to see where they should be
> mounted in the FS. xattrs may include mount options and special
> flags.

I am working to prototype something like that. A "mount.btrfs" command which
1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)

2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)

My idea is that the subvolume are grouped so:

@<name>				simple subvolume
@<name>.<timestamp>		snapshot of subvolume <name>
@<name>.rollback		rollback subvolume

If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)

For each @<name> subvolume the following xattrs are considered:
user.btrfs.automount=1|0	the subvolume has to be automounted
user.btrfs.mntpoint=<path>	subvolume mount point


So this "mount.btrsf" command should:

1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
2) performing the auto rollback (this behaviour can be controlled by another xattr)
3) mount the subvolume "@" as "root" (like the default one) in the right mount point
4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
to allow managing (snapshot) of the different subvolumes.

Thoughts ?

BR
G.Baroncelli

> 
> mount the things you find
> 
> umount /search_for_fstab
> 
> I like that it's not actually btrfs specific, since the bind mounts
> will work for any FS. But it naturally fits the /@ namespace that we
> seem to be favoring as a collection point for snapshots and
> subvolumes. 
> -chris
> 
> 
> 
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Murphy]

On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:

> On 03/12/2014 06:24 PM, Chris Mason wrote:
>> 
>> 
>> On 03/10/2014 07:45 PM, Lennart Poettering wrote:
>>> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
>>> 
>>>>> Well, the name is property of the admin really. There needs to be a way
>>>>> how the admin can label his subvolumes, with a potentially localized
>>>>> name. This makes it unsuitable for our purpose, we cannot just take
>>>>> possession of this and leave the admin with nothing.
>>>> 
>>>> Instead of the name we can use the xattr to store these information.
>>> 
>>> Ah, using xattrs for this is indeed an option. That way we should be able
>>> attach any kind of information we like to a subvolume.
>>> 
>>> Hmm, I figure though that there is no way currently to read xattrs off a
>>> subvolume without first mounting them individually? Having to mount all
>>> subvolumes before we can make sense of them and mount them to the right
>>> place certainly sounds less than ideal...
>> 
>> Ok, are we hoping to pull the xattrs off the disk before mounting
>> anything? Or can we do a mount in a side directory first to scan for
>> subvols?
>> 
>> I like the idea of something like this:
>> 
>> mount device on /search_for_fstab cd
>> /search_for_fstab/<some_magic_directory_name_option_in_systemd>
>> 
>> read xattrs on directories it finds to see where they should be
>> mounted in the FS. xattrs may include mount options and special
>> flags.
> 
> I am working to prototype something like that. A "mount.btrfs" command which
> 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)
> 
> 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)
> 
> My idea is that the subvolume are grouped so:
> 
> @<name>				simple subvolume
> @<name>.<timestamp>		snapshot of subvolume <name>
> @<name>.rollback		rollback subvolume
> 
> If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)
> 
> For each @<name> subvolume the following xattrs are considered:
> user.btrfs.automount=1|0	the subvolume has to be automounted
> user.btrfs.mntpoint=<path>	subvolume mount point
> 
> 
> So this "mount.btrsf" command should:
> 
> 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
> 2) performing the auto rollback (this behaviour can be controlled by another xattr)
> 3) mount the subvolume "@" as "root" (like the default one) in the right mount point
> 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
> 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
> to allow managing (snapshot) of the different subvolumes.
> 
> Thoughts ?

In effect this obviates boot parameter rootflags=subvol= since the file system metadata self-describe the subvol to be mounted, correct?

Your suggestion also sounds like it places snapshots outside of their parent subvolume? If so it mitigates a possible security concern if the snapshot contains (old) binaries with vulnerabilities. I asked about how to go about assessing this on the Fedora security list:
https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html

There aren't many replies but the consensus is that it's a legitimate concern, so either the snapshots shouldn't be persistently available (which is typical with e.g. snapper, and also yum-plugin-fs-snapshot), and/or when the subvolume containing snapshots is mounted, it's done with either mount option noexec or nosuid (no consensus on which one, although Gnome Shell uses nosuid by default when automounting removable media).



Chris Murphy

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/12/2014 08:31 PM, Chris Murphy wrote:
> 
> On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
> 
[...]
>>
>> I am working to prototype something like that. A "mount.btrfs" command which
>> 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)
>>
>> 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)
>>
>> My idea is that the subvolume are grouped so:
>>
>> @<name>				simple subvolume
>> @<name>.<timestamp>		snapshot of subvolume <name>
>> @<name>.rollback		rollback subvolume
>>
>> If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)
>>
>> For each @<name> subvolume the following xattrs are considered:
>> user.btrfs.automount=1|0	the subvolume has to be automounted
>> user.btrfs.mntpoint=<path>	subvolume mount point
>>
>>
>> So this "mount.btrsf" command should:
>>
>> 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
>> 2) performing the auto rollback (this behaviour can be controlled by another xattr)
>> 3) mount the subvolume "@" as "root" (like the default one) in the right mount point
>> 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
>> 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
>> to allow managing (snapshot) of the different subvolumes.
>>
>> Thoughts ?
> 
> In effect this obviates boot parameter rootflags=subvol= since the
> file system metadata self-describe the subvol to be mounted,
> correct?
Definetely; 
> 
> Your suggestion also sounds like it places snapshots outside of their
> parent subvolume? 
yes, to me snapshot and "parent subvolume" are sibling more than parent/child. This simplify the rollback scenario. For example using the convention above we can rollback all the subvolumes mounting all the snapshots where the timestamp is less than the desired value.

> If so it mitigates a possible security concern if
> the snapshot contains (old) binaries with vulnerabilities. I asked
> about how to go about assessing this on the Fedora security list: 
> https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html
>
> There aren't many replies but the consensus is that it's a legitimate
> concern, so either the snapshots shouldn't be persistently available
> (which is typical with e.g. snapper, and also
> yum-plugin-fs-snapshot), and/or when the subvolume containing
> snapshots is mounted, it's done with either mount option noexec or
> nosuid (no consensus on which one, although Gnome Shell uses nosuid
> by default when automounting removable media). 

Interesting observation
> 
> 
> Chris Murphy
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/12/2014 08:12 PM, Goffredo Baroncelli wrote:
[...]
> I am working to prototype something like that. A "mount.btrfs" command which
> 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)
> 
> 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)
> 
> My idea is that the subvolume are grouped so:
> 
> @<name>				simple subvolume
> @<name>.<timestamp>		snapshot of subvolume <name>
> @<name>.rollback		rollback subvolume
> 
> If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)
> 
> For each @<name> subvolume the following xattrs are considered:
> user.btrfs.automount=1|0	the subvolume has to be automounted
> user.btrfs.mountpoint=<path>	subvolume mount point
> 
> 
> So this "mount.btrfs" command should:
> 
> 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
> 2) performing the auto rollback (this behaviour can be controlled by another xattr)
> 3) mount the subvolume "@" as "root" (like the default one) in the right mount point
> 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
> 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
> to allow managing (snapshot) of the different subvolumes.
> 


Below my POC.

$ sudo mount /dev/loop0 t
$ sudo getfattr -d t/{@*,.}
# file: t/@
user.btrfs.automount="1"

# file: t/@__boot__
user.btrfs.automount="1"
user.btrfs.mountpoint="/boot"

# file: t/@.broken-0
user.btrfs.automount="1"

# file: t/@.broken-1
user.btrfs.automount="1"

# file: t/@__home__
user.btrfs.automount="1"
user.btrfs.mountpoint="/home"

# file: t/@__root__.12345
user.btrfs.automount="0"

# file: t/@space space
user.btrfs.automount="0"

# file: t/@__srv__
user.btrfs.automount="0"

# file: t/.
user.btrfs.automount="1"
user.btrfs.autorollback="1"
user.btrfs.mountpoint="/var/btrfs"

$ sudo umount t


$ sudo sh mount.btrfs /dev/loop0 t
Mount /dev/loop0/@ ->  t
Mount /dev/loop0/@__boot__ ->  t//boot
Mount /dev/loop0/@__home__ ->  t//home
Mount /dev/loop0 -> t//var/btrfs
ghigo@venice:~/btrfs/mount-btrfs$ find t
t
t/var
t/var/btrfs
t/var/btrfs/@__boot__
t/var/btrfs/@__home__
t/var/btrfs/@__srv__
t/var/btrfs/@__root__.12345
t/var/btrfs/@space space
t/var/btrfs/@.broken-0
t/var/btrfs/@.broken-0/var
t/var/btrfs/@.broken-0/var/btrfs
t/var/btrfs/@.broken-0/@__boot__
t/var/btrfs/@.broken-0/@__home__
t/var/btrfs/@.broken-0/boot
t/var/btrfs/@.broken-0/home
t/var/btrfs/@.broken-0/non-rollback-subvol
t/var/btrfs/@.broken-1
t/var/btrfs/@.broken-1/var
t/var/btrfs/@.broken-1/var/btrfs
t/var/btrfs/@.broken-1/@__boot__
t/var/btrfs/@.broken-1/@__home__
t/var/btrfs/@.broken-1/boot
t/var/btrfs/@.broken-1/home
t/var/btrfs/@.broken-1/rollback-subvol
find: File system loop detected; ‘t/var/btrfs/@’ is part of the same file system loop as ‘t’.
t/@__boot__
t/@__home__
t/boot
t/home
t/non-rollback-subvol





$cat mount.btrfs
#!/bin/sh

XAAMOUNT="user.btrfs.automount"
XAAMNTPNT="user.btrfs.mountpoint"
XAAROLLBACK="user.btrfs.autorollback"

xdebug() {
    [ -z "$DEBUG" ] && return
    echo "$@"
}

autorollback() {

    ( cd "$tmpdir"; ls -d @*.rollback 2>/dev/null) | while read drb; do
    
        rbfullpath="$tmpdir/$drb"
        [ ! -d "$rbfullpath" ] && continue
        is_btrfs_subvol "$rbfullpath" || continue
        
        f="$(get_fattr $XAAROLLBACK "$rbfullpath" )"
        [ "x$f" = "x0" ] && continue

        d="$(echo $drb | sed -e "s/.rollback$//")"
        fullpath="$tmpdir/$d"
        
        if [ -d "$fullpath" ]; then
            f="$(get_fattr $XAAROLLBACK "$fullpath" )"
            [ "x$f" = "x0" ] && continue
            
            i=0
            while true; do
                newfullpath="$fullpath.broken-$i"
                if [ ! -e  "$newfullpath" ]; then
                    mv "$fullpath" "$newfullpath"
                    break
                fi
                i=$(($i+1))
            done
        fi
        
        echo "Rollback $d"
        mv "$rbfullpath" "$fullpath"

    done
    
}

is_btrfs_subvol() {
    [ "$(stat -c "%i" "$1")" -eq "256" ]
}

get_fattr() {

    name="$1"
    file="$2"

    getfattr --only-values -n "$name" "$file" 2>/dev/null || echo -n ""

}

automount() {
    tmpdir="$1"
    srcdev="$2"
    mntpnt="$3"

    fullpath="$tmpdir/@"
    [ ! -d "$fullpath" ] && return 1

    is_btrfs_subvol "$fullpath" || return 1
    b="$(get_fattr $XAAMOUNT "$fullpath" )"
    [ "x$b" = "x0" ] && return 1
    
    path="$(get_fattr $XAAMNTPNT "$fullpath" )"
    if [ -n "$path" ] ; then
        mntpnt="$path"
    fi
    xdebug mount -o "subvol=@" "$srcdev" "$mntpnt/"
    echo "Mount $srcdev/@ ->  $mntpnt"
    mount -o "subvol=@" "$srcdev" "$mntpnt/" || return 1
    

    ( cd "$tmpdir"; ls -d @*  2>/dev/null) |  grep -v "\." | while read d; do
    
        [ "x$d" = "x./@" ] && continue
        
        fullpath="$tmpdir/$d"
        [ ! -d "$fullpath" ] && continue
        
        is_btrfs_subvol "$fullpath" || continue
        
        path="$(get_fattr $XAAMNTPNT "$fullpath" )"
        [ -z "$path" ] && continue
        
        b="$(get_fattr $XAAMOUNT "$fullpath" )"
        [ "x$b" = "x0" ] && continue
        
        echo "Mount $srcdev/$d ->  $mntpnt/$path"
        xdebug mount -o "subvol=$d" "$srcdev" "$mntpnt/$path"
        mkdir -p "$mntpnt/$path"
        mount -o "subvol=$d" "$srcdev" "$mntpnt/$path"

    done
    
    return 0

}

main() {
    #create tempdir
    tmpdir=$(mktemp --directory)

    srcdev="$1"
    mntpnt="$2"

    xdebug mount -t btrfs "$srcdev" "$tmpdir" 
    mount -o subvolid=5 -t btrfs "$srcdev" "$tmpdir" || exit

    # get the global value
    GLOBALAMOUNT=$(get_fattr $XAAMOUNT "$tmpdir/.")
    GLOBALAROLLBACK=$(get_fattr $XAAROLLBACK "$tmpdir/.")
    BTRFSROOT="$(get_fattr $XAAMNTPNT "$tmpdir/." )"
    xdebug "GLOBALAMOUNT=$GLOBALAMOUNT, GLOBALAROLLBACK=$GLOBALAROLLBACK"

    if [ "x$GLOBALAROLLBACK" = "x1" ]; then
        autorollback "$tmpdir"
    fi

    if [ "x$GLOBALAMOUNT" = "x1" ]; then
        if ! automount "$tmpdir" "$srcdev" "$mntpnt"; then
            echo 1>&2 "ERROR: unable to mount the filesystem"
            exit 10
        fi

        umount "$tmpdir"
        if [ -n "$BTRFSROOT" ]; then
            mkdir -p "$mntpnt/$BTRFSROOT"
            echo "Mount $srcdev -> $mntpnt/$BTRFSROOT"
            mount -o subvolid=5 "$srcdev" "$mntpnt/$BTRFSROOT"
        fi

    else
        mount --move "$tmpdir" "$mntpnt"
    fi

}

#FIXME: allow options
if [ $# -ne 2 ]; then
    echo "usage: $0 <srcdev> <mount-point>"
    exit 1
fi
main "$@"


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Brendan Hide]

On 2014/03/12 09:31 PM, Chris Murphy wrote:
> On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
>> On 03/12/2014 06:24 PM, Chris Mason wrote:
> Your suggestion also sounds like it places snapshots outside of their parent subvolume? If so it mitigates a possible security concern if the snapshot contains (old) binaries with vulnerabilities. I asked about how to go about assessing this on the Fedora security list:
> https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html
>
> There aren't many replies but the consensus is that it's a legitimate concern, so either the snapshots shouldn't be persistently available (which is typical with e.g. snapper, and also yum-plugin-fs-snapshot), and/or when the subvolume containing snapshots is mounted, it's done with either mount option noexec or nosuid (no consensus on which one, although Gnome Shell uses nosuid by default when automounting removable media).
This is exactly the same result if following the previously-recommended 
subvolume layout given on the Arch wiki. It seems this wiki advice has 
"disappeared" so I can't give a link for it ...

My apologies if the rest of my mail is off-topic.

Though not specifically for rollback, my snapshots prior to btrfs {send 
| , receive} backup is done via temporary mountpoint. Until two days ago 
I was still using rsync to a secondary btrfs volume and the __snapshots 
folder had been sitting empty for about a year. The performance 
difference with send|receive is magnitudes apart: A daily backup to the 
secondary disk now takes between 30 and 40 seconds whereas it took 20 to 
30 minutes with rsync.

Here are my current subvolumes:
__active
__active/home
__active/usr
__active/var
__snapshots/__2014-03-12-23h00m01s+0200
__snapshots/_home_2014-03-12-23h00m01s+0200
__snapshots/_usr_2014-03-12-23h00m01s+0200
__snapshots/_var_2014-03-12-23h00m01s+0200

I hadn't thought of noexec or nosuid. On a single-user system you don't 
really expect that type of incursion. I will put up my work after I've 
properly automated cleanup.

The only minor gripe I have with the temporary mount is that I feel it 
should be possible to perform snapshots and use send|receive without the 
requirement of having the subvolumes be "visible" in userspace.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97