property designating root subvolumes

[Eric Levy <contact@ericlevy.name>]

The file system allows one subvolume per partition to be designated as 
the default, and no more than one would be sensible. Generally, for 
partitions organized with a base file hierarchy constituted of multiple 
subvolumes, the one representing the root mount would be designated as 
the default. Although this association is not required, it is a 
reasonable assumption, enough so that some tools depend on it for 
certain features. For example, the rEFInd bootloader scans a BTRFS file 
system for a Linux-based OS by attempting to identify a root file 
hierarchy on the default subvolume. However, in such usage, the 
constraint of one subvolume designated per partition is limiting. In 
principle, a bootloader might support multiple operating systems 
installed on the same partition, as long as each root partition may be 
separately indicated. To support such usage, it might be helpful if a 
property, separate from the designation of a default subvolume, was 
supported. As a property, it would be allowed to be assigned 
arbitrarily to any number of subvolumes.

Presently, rEFInd supports multiple operating systems on different 
subvolumes of the same partition only by static configuration. Such a 
constraint is particularly cumbersome because any operation for 
installing the bootloader utilizes configuration only on the active 
operating system.

In principle, the broader concept might be extended further, adding 
even more properties, for supporting yet further use cases. As one 
example, a subvolume might be selected as containing configuration 
information applicable to the bootloader, regardless of the active 
operating system. Such a feature would facilitate synchronization of 
bootloader settings for installation tools across all operating systems 
on a partition. Yet, even the single new property would support cleaner 
semantics for greater flexibility of usage.

Note that for such a feature to work properly, the file system would 
need to enforce that the property not be inherited by child volumes, 
that is, snapshots derived from a subvolume with the property enabled. 
Furthermore, some thought must be given to the case of the user 
enabling the property for a subvolume having an ancestor with the 
property already enabled. In such a case, it most likely is desired 
that the property would be disabled for the ancestor.