Discoverable Partitions Spec
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Lennart Poettering
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstabunnecessary 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
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 12 lines · Goffredo Baroncelli
Quoted 9 lines · Lennart Poettering
Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstabunnecessary 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/
Quoted 8 lines
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
Hi Kay
On 03/10/2014 07:53 PM, Kay Sievers wrote:
[...]
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
KayGoffredo--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 13 lines · Goffredo Baroncelli
Quoted 11 lines · Lennart Poettering
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstabunnecessary 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/
Quoted 8 lines
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
On Mon, 10.03.14 19:34, Goffredo Baroncelli ([email protected]) wrote:
Heya,
Quoted 8 lines
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.
Quoted 8 lines
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
Signature · 1 line
Lennart Poettering, Red Hat
Quoted 32 lines · Lennart Poettering
On Mon, 10.03.14 19:34, Goffredo Baroncelli ([email protected]) wrote:
Heya,
Quoted 8 lines
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.
Quoted 8 lines
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
Quoted 6 lines
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
Quoted 33 lines · Chris Mason
Quoted 32 lines · Lennart Poettering
On Mon, 10.03.14 19:34, Goffredo Baroncelli ([email protected]) wrote:
Heya,
Quoted 8 lines
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.
Quoted 8 lines
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
Quoted 8 lines
Quoted 6 lines
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.
Quoted 1 line
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
Quoted 13 lines · Chris Murphy
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.
Quoted 4 lines
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
Signature · 1 line
Lennart Poettering, Red Hat
Quoted 2 lines · Chris Mason
Quoted 1 line · Lennart Poettering
On Mon, 10.03.14 19:34, Goffredo Baroncelli ([email protected]) wrote:
[...]
Quoted 7 lines
Quoted 6 lines
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...
Quoted 7 lines
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.
Quoted 7 lines
-chris
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 13 lines · Lennart Poettering
On Mon, 10.03.14 19:34, Goffredo Baroncelli ([email protected]) wrote:
Heya,
Quoted 8 lines
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
[...]
Quoted 4 lines
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.
Quoted 14 lines
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.
Quoted 8 lines
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
Quoted 6 lines
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.
Quoted 3 lines
Lennart
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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...
Quoted 21 lines
Quoted 14 lines
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.
Quoted 8 lines
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 systemQuoted 6 lines
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...
Quoted 5 lines
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
Signature · 1 line
Lennart Poettering, Red Hat
Quoted 9 lines · Lennart Poettering
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
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.
Quoted 9 lines
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 systemI 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...
Quoted 7 lines
Quoted 5 lines
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.
Quoted 2 lines
Lennart
Quoted 9 lines · Lennart Poettering
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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.
Quoted 7 lines
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.
Signature · 1 line
Calvin Walton <[email protected]>
Quoted 9 lines · Lennart Poettering
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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.
Quoted 7 lines
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
Quoted 24 lines · Chris Mason
Quoted 9 lines · Lennart Poettering
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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.
Quoted 7 lines
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?
Quoted 8 lines
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
Quoted 15 lines
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
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 54 lines · Goffredo Baroncelli
Quoted 24 lines · Chris Mason
Quoted 9 lines · Lennart Poettering
Quoted 6 lines · Goffredo Baroncelli
Quoted 4 lines
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.
Quoted 7 lines
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?
Quoted 8 lines
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 subvolumeIf @<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 pointSo this "mount.btrsf" command should:
Quoted 8 lines
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
Quoted 3 lines · Chris Murphy
On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <[email protected]> wrote:
[...]
Quoted 28 lines
Quoted 28 lines
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 subvolumeIf @<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 pointSo 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.
Quoted 5 lines
Quoted 1 line
Thoughts ?
In effect this obviates boot parameter rootflags=subvol= since the file system metadata self-describe the subvol to be mounted, correct?
Definetely;
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 7 lines
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
Quoted 5 lines
Chris Murphy
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Quoted 6 lines · Chris Murphy
Quoted 1 line · Goffredo Baroncelli
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.htmlThere 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.
Signature · 4 lines
__________ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97
On 03/12/2014 08:12 PM, Goffredo Baroncelli wrote:
[...]
Quoted 18 lines
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 subvolumeIf @<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
Quoted 9 lines
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 1fi
main "$@"
Signature · 2 lines
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5