Lennart Poettering wrote: > On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@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 > -- 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
