On 03/10/2014 04:02 PM, Lennart Poettering wrote:
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
