On Wed, Oct 19, 2016 at 03:33:03PM +0200, Cyril Brulebois wrote:
> Hi,
>
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.
>
> Feel free to mention packages you want to see in testing, in case I go
> for a conservative approach (and only hand-pick a few packages); feel
> free to cc me explicitly to make sure I read your replies.
>
>
> KiBi.
What is my deadline for adding minimal subvolume support to
partman-btrfs? If it needs to be done in the next 24h, my plan is to
default to creating a subvolume called @ for each btrfs volume and
silently add subvol=@ to the mount options and fstab entries for these
volumes. With this change there is a 1-to-1-to-1
partition-to-volume-to-subvolume mapping.
I'd like to start with this, just to make sure the various bootloaders
handle it cleanly; I'm 95% certain the existing grub-install logic
will handle this change without incident, but I'm not sure about other
bootloaders on other architectures. That might take some time to
shake out...essentially, the bootloader needs to detect that /target
is mounted with -o subvol=@ and add rootflags=subvol=@ to the kernel
command line.
What is my deadline for more complete btrfs support? What
documentation can I consult when working on this? I've been spending
time reading everything in partman-lvm, and partman-zfs, but I feel
like I'm going to miss the deadline at this rate. Specifically my
plan is to:
1. Add a "Configure btrfs volumes" option underneath "Configure
encrypted volumes":
2. Partitions that are configured to be used as "btrfs journaling
file system" appear in this menu, just like a raid-configured
partition appears in "configure software raid"
3. Then it offers two options "configure profile" and "configure
subvolumes.
3.a - The following "configure profile" menu appears.
i. Single (similar to lvm append) data with raid1 (two copies on
different devices) metadata
ii. Raid0 data with raid1 metadata
iii. Raid1 data and raid1 metadata
p.s. In the future, when raid5/6 stabilise they can be added as
option. I believe the above options strike the balance
between what is currently most featureful and as safe as
possible.
p.p.s. If a user wants to live dangerously, he/she can rebalance a
live system to raid0 metadata for maximum performance, or any
other possible btrfs profile after installation completes and
is rebooted
iv. The next menu is like the "active devices for the raid1 array"
* default to creating @rootfs, and configure / on @rootfs; then mount
-o subvolume=@rootfs /target. In the main "Partition Disks" screen
there will be a btrfs volume heading which displays this
configuration.
3.b - Configure subvolume menu; this functions similarly to "Configure
the Logical Volume Manager" menu, after an PV has been
designated, and after a VG has been created.
i. When the user enters this menu, @rootfs is preconfigured and
a list of existing subvolumes is shown.
iii. The only two options are create and delete subvolume
(equivalent to LVM create LV and delete LV)
--
3.b.alt Would it be better UI design to skip the branch from 3 -> 3.a
|| 3.b inside of btrfs options, and instead write a new
"Partition disks" mode which appears under an "available btrfs
volumes". If we use this method instead, then once a btrfs
volume's profile (equivalent to [mdadm +] pv+vg) configured in
3.a it will appear with its "btrfs volume" heading above the
physical partitioning section on the main "partition disks"
screen. By default, the item "create subvolume" will appear
under the volume heading. Like the "Partition Disks"
"Partition settings" it allows configuration of Name, Mount
point, but in addition to these only the Remove subvolume and
Done setting up subvolume menu options are provided. If there
is not something configured to be mounted at /, then the first
time the "create subvolume" screen is invoked Name will be
preconfigured to @rootfs.
Because per-subvolume mount options are unsupported or poorly defined,
by default btrfs volumes will be configure with -o default in
/etc/fstab. The 3.b or 3.b.alt configuration is what generates the
subvol=@probably_should_be_limited_to_ASCII_name. mount option used in
fstab.
So yeah, with this plan Debian Stretch's installer finally have
equivalent btrfs support to other major distributions :-)
Any advice or reference material would be very much appreciated!
Sincerely,
Nicholas
Attachment:
signature.asc
Description: Digital signature