* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec [not found] <20140307182603.GA22874@tango.0pointer.de> @ 2014-03-10 18:34 ` Goffredo Baroncelli 2014-03-10 18:53 ` Kay Sievers ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-10 18:34 UTC (permalink / raw) To: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli @ 2014-03-10 18:53 ` Kay Sievers 2014-03-10 18:59 ` Goffredo Baroncelli 2014-03-10 19:43 ` Chris Murphy 2014-03-10 20:02 ` Lennart Poettering 2 siblings, 1 reply; 19+ messages in thread From: Kay Sievers @ 2014-03-10 18:53 UTC (permalink / raw) To: kreijack; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 18:53 ` Kay Sievers @ 2014-03-10 18:59 ` Goffredo Baroncelli 0 siblings, 0 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-10 18:59 UTC (permalink / raw) To: Kay Sievers; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli 2014-03-10 18:53 ` Kay Sievers @ 2014-03-10 19:43 ` Chris Murphy 2014-03-10 20:02 ` Lennart Poettering 2 siblings, 0 replies; 19+ messages in thread From: Chris Murphy @ 2014-03-10 19:43 UTC (permalink / raw) To: systemd-devel; +Cc: linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli 2014-03-10 18:53 ` Kay Sievers 2014-03-10 19:43 ` Chris Murphy @ 2014-03-10 20:02 ` Lennart Poettering 2014-03-10 20:21 ` Chris Mason 2014-03-10 22:39 ` Goffredo Baroncelli 2 siblings, 2 replies; 19+ messages in thread From: Lennart Poettering @ 2014-03-10 20:02 UTC (permalink / raw) To: kreijack; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 20:02 ` Lennart Poettering @ 2014-03-10 20:21 ` Chris Mason 2014-03-10 20:53 ` Chris Murphy 2014-03-10 22:44 ` Goffredo Baroncelli 2014-03-10 22:39 ` Goffredo Baroncelli 1 sibling, 2 replies; 19+ messages in thread From: Chris Mason @ 2014-03-10 20:21 UTC (permalink / raw) To: Lennart Poettering, kreijack; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 20:21 ` Chris Mason @ 2014-03-10 20:53 ` Chris Murphy 2014-03-10 21:09 ` Lennart Poettering 2014-03-10 22:44 ` Goffredo Baroncelli 1 sibling, 1 reply; 19+ messages in thread From: Chris Murphy @ 2014-03-10 20:53 UTC (permalink / raw) To: Chris Mason; +Cc: Lennart Poettering, kreijack, systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 20:53 ` Chris Murphy @ 2014-03-10 21:09 ` Lennart Poettering 0 siblings, 0 replies; 19+ messages in thread From: Lennart Poettering @ 2014-03-10 21:09 UTC (permalink / raw) To: Chris Murphy; +Cc: Chris Mason, kreijack, systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 20:21 ` Chris Mason 2014-03-10 20:53 ` Chris Murphy @ 2014-03-10 22:44 ` Goffredo Baroncelli 1 sibling, 0 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-10 22:44 UTC (permalink / raw) To: Chris Mason, Lennart Poettering; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 20:02 ` Lennart Poettering 2014-03-10 20:21 ` Chris Mason @ 2014-03-10 22:39 ` Goffredo Baroncelli 2014-03-10 23:45 ` Lennart Poettering 1 sibling, 1 reply; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-10 22:39 UTC (permalink / raw) To: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 22:39 ` Goffredo Baroncelli @ 2014-03-10 23:45 ` Lennart Poettering 2014-03-10 23:59 ` Alex Elsayed ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Lennart Poettering @ 2014-03-10 23:45 UTC (permalink / raw) To: kreijack; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [HEADS-UP] Discoverable Partitions Spec 2014-03-10 23:45 ` Lennart Poettering @ 2014-03-10 23:59 ` Alex Elsayed 2014-03-11 14:30 ` [systemd-devel] " Calvin Walton 2014-03-12 17:24 ` Chris Mason 2 siblings, 0 replies; 19+ messages in thread From: Alex Elsayed @ 2014-03-10 23:59 UTC (permalink / raw) To: linux-btrfs; +Cc: systemd-devel 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 23:45 ` Lennart Poettering 2014-03-10 23:59 ` Alex Elsayed @ 2014-03-11 14:30 ` Calvin Walton 2014-03-12 17:24 ` Chris Mason 2 siblings, 0 replies; 19+ messages in thread From: Calvin Walton @ 2014-03-11 14:30 UTC (permalink / raw) To: Lennart Poettering; +Cc: kreijack, systemd-devel, linux-btrfs 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-10 23:45 ` Lennart Poettering 2014-03-10 23:59 ` Alex Elsayed 2014-03-11 14:30 ` [systemd-devel] " Calvin Walton @ 2014-03-12 17:24 ` Chris Mason 2014-03-12 19:12 ` Goffredo Baroncelli 2 siblings, 1 reply; 19+ messages in thread From: Chris Mason @ 2014-03-12 17:24 UTC (permalink / raw) To: Lennart Poettering, kreijack; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-12 17:24 ` Chris Mason @ 2014-03-12 19:12 ` Goffredo Baroncelli 2014-03-12 19:31 ` Chris Murphy 2014-03-12 22:18 ` Goffredo Baroncelli 0 siblings, 2 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-12 19:12 UTC (permalink / raw) To: Chris Mason; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-12 19:12 ` Goffredo Baroncelli @ 2014-03-12 19:31 ` Chris Murphy 2014-03-12 19:55 ` Goffredo Baroncelli 2014-03-12 23:22 ` Brendan Hide 2014-03-12 22:18 ` Goffredo Baroncelli 1 sibling, 2 replies; 19+ messages in thread From: Chris Murphy @ 2014-03-12 19:31 UTC (permalink / raw) To: kreijack; +Cc: Chris Mason, systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-12 19:31 ` Chris Murphy @ 2014-03-12 19:55 ` Goffredo Baroncelli 2014-03-12 23:22 ` Brendan Hide 1 sibling, 0 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-12 19:55 UTC (permalink / raw) To: Chris Murphy; +Cc: Chris Mason, systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-12 19:31 ` Chris Murphy 2014-03-12 19:55 ` Goffredo Baroncelli @ 2014-03-12 23:22 ` Brendan Hide 1 sibling, 0 replies; 19+ messages in thread From: Brendan Hide @ 2014-03-12 23:22 UTC (permalink / raw) To: Chris Murphy, kreijack; +Cc: Chris Mason, systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec 2014-03-12 19:12 ` Goffredo Baroncelli 2014-03-12 19:31 ` Chris Murphy @ 2014-03-12 22:18 ` Goffredo Baroncelli 1 sibling, 0 replies; 19+ messages in thread From: Goffredo Baroncelli @ 2014-03-12 22:18 UTC (permalink / raw) To: Chris Mason; +Cc: systemd-devel, linux-btrfs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-03-12 23:34 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20140307182603.GA22874@tango.0pointer.de>
2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli
2014-03-10 18:53 ` Kay Sievers
2014-03-10 18:59 ` Goffredo Baroncelli
2014-03-10 19:43 ` Chris Murphy
2014-03-10 20:02 ` Lennart Poettering
2014-03-10 20:21 ` Chris Mason
2014-03-10 20:53 ` Chris Murphy
2014-03-10 21:09 ` Lennart Poettering
2014-03-10 22:44 ` Goffredo Baroncelli
2014-03-10 22:39 ` Goffredo Baroncelli
2014-03-10 23:45 ` Lennart Poettering
2014-03-10 23:59 ` Alex Elsayed
2014-03-11 14:30 ` [systemd-devel] " Calvin Walton
2014-03-12 17:24 ` Chris Mason
2014-03-12 19:12 ` Goffredo Baroncelli
2014-03-12 19:31 ` Chris Murphy
2014-03-12 19:55 ` Goffredo Baroncelli
2014-03-12 23:22 ` Brendan Hide
2014-03-12 22:18 ` Goffredo Baroncelli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).