Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Fri, 14.03.14 14:49, Koen Kooi (koen.k...@linaro.org) wrote: It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. So how do I get UUIDs allocated for 32bit and 64bit ARM? Do you use GPT on ARM? I have now added them to the spec and systemd, since people kept asking all the time... They are not too useful though for avoiding root= on the kernel cmdline, since we only look for root disks on the ESP partition, and EFI isn't that real on ARM... But it might be useful for systemd-nspawn -i, and thus I added it now. I wonder if I should just add one for each arch we support, to put an end to the story... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
Op 14 mrt. 2014, om 15:23 heeft Lennart Poettering lenn...@poettering.net het volgende geschreven: On Fri, 14.03.14 14:49, Koen Kooi (koen.k...@linaro.org) wrote: It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. So how do I get UUIDs allocated for 32bit and 64bit ARM? Do you use GPT on ARM? The short answer: yes. I have now added them to the spec and systemd, since people kept asking all the time... They are not too useful though for avoiding root= on the kernel cmdline, since we only look for root disks on the ESP partition, and EFI isn't that real on ARM... ARM ltd. likes to pretend arm64 will be UEFI+ACPI only, but yes, it's not that real yet. Having said that, what prompted this was the discussion of the portable container format, which mandates an ESP partition. If we're going to do that on arm we should also make sure to supports this partition spec :) regards, Koen But it might be useful for systemd-nspawn -i, and thus I added it now. I wonder if I should just add one for each arch we support, to put an end to the story... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli kreij...@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 (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... 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=pathsubvolume 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/12/2014 08:31 PM, Chris Murphy wrote: On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli kreij...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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 \. |
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli kreij...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mar 10, 2014, at 12:34 PM, Goffredo Baroncelli kreij...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mar 10, 2014, at 2:21 PM, Chris Mason c...@fb.com wrote: 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Mon, 10.03.14 14:53, Chris Murphy (li...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/10/2014 09: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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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 (kreij...@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 majord...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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... 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering lenn...@poettering.net 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/ It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. That might not work very well if one tried to dual-boot two systemd distros… FAQ #1 talks about /usr and /etc, but /etc is almost always in the root partition, isn't it? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On Fri, 07.03.14 20:47, Mantas Mikulėnas (graw...@gmail.com) wrote: On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering lenn...@poettering.net 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/ It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. That might not work very well if one tried to dual-boot two systemd distros… Hmm? there are all kinds of provisions in the spec to make sure this works correctly. For example, we won't do this all for /usr and /var and /etc since we cannot allow incorrect mixing and matching between parallel installations. However, for /home and /srv that is much less of a problem, and sharing should be *good* in that case. And for the root disk we declare explicitly that installers may only drop the root= param from the kernel cmdline if the OS is installed as first root partition on the disk. Otherwise it *must* specify it to make sure the right partition is found at boot. Putting this altogether this should work fine for multi-boot cases. That said, the benefit of not requiring an /etc/fstab is primarily one for simpler appliance style disk images where only one OS is installed, not for the super generic full distro cases that want to support every possible storage setup. For example, I wouldn't expect anaconda to ever drop the root= param from the kernel cmdline of its installations. I mean, given that anaconda wants to support booting LVM on LUKS on RAID and iscsi on bonded vlans and whatever else, there's no auto-discovery like this possible anyway, and hence they can just keep the root= in there for everybody... FAQ #1 talks about /usr and /etc, but /etc is almost always in the root partition, isn't it? Well, sure it is, and so is /var... But it certainly makes sense to have a seperate /etc in some cases. For example, in virtualized environments it might make sense to share a single fixed read-only /usr between a large number of containers that each have a private /etc and /var. I mean, this is the FAQ section, I am not saying whether splitting these things makes sense or no sense at all, I am just saying that auto-discovery makes no sense for these cases... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
В Fri, 7 Mar 2014 20:37:12 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 07.03.14 20:47, Mantas Mikulėnas (graw...@gmail.com) wrote: On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering lenn...@poettering.net 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/ It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. That might not work very well if one tried to dual-boot two systemd distros… Hmm? there are all kinds of provisions in the spec to make sure this works correctly. For example, we won't do this all for /usr and /var and /etc since we cannot allow incorrect mixing and matching between parallel installations. However, for /home and /srv that is much less of a problem, and sharing should be *good* in that case. And for the root disk we declare explicitly that installers may only drop the root= param from the kernel cmdline if the OS is installed as first root partition on the disk. Otherwise it *must* specify it to make sure the right partition is found at boot. Putting this altogether this should work fine for multi-boot cases. That said, the benefit of not requiring an /etc/fstab is primarily one for simpler appliance style disk images where only one OS is installed, not for the super generic full distro cases that want to support every possible storage setup. For example, I wouldn't expect anaconda to ever drop the root= param from the kernel cmdline of its installations. I mean, given that anaconda wants to support booting LVM on LUKS on RAID and iscsi on bonded vlans and whatever else, there's no auto-discovery like this possible anyway, and hence they can just keep the root= in there for everybody... So what is the benefit of creating specification and tools that nobody will use? If distributions will have to support explicit filesystem configuration anyway, what is the benefit for them to add *additional* support for automatic configuration? Especially if this automatic configuration is incomplete and has to be augmented with explicit configuration anyway. FAQ #1 talks about /usr and /etc, but /etc is almost always in the root partition, isn't it? Well, sure it is, and so is /var... But it certainly makes sense to have a seperate /etc in some cases. For example, in virtualized environments it might make sense to share a single fixed read-only /usr between a large number of containers that each have a private /etc and /var. I mean, this is the FAQ section, I am not saying whether splitting these things makes sense or no sense at all, I am just saying that auto-discovery makes no sense for these cases... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
2014-03-08 1:37 GMT+06:00 Lennart Poettering lenn...@poettering.net: And for the root disk we declare explicitly that installers may only drop the root= param from the kernel cmdline if the OS is installed as first root partition on the disk. Otherwise it *must* specify it to make sure the right partition is found at boot. I see a potential problem here. Even if this partition is the first root partition now, there is no guarantee that it will remain to be the first root partition after one frees an existing data partition (that happened to go before root) and installs the next linux distro on it. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
