Re: joining the team
On 23 April 2016 at 07:28, Philipp Kern <pkern@debian.org> wrote:
> Hi,
>
> On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote:
>> I'd like to join the Debian Installer installer team to work on better
>> btrfs integration. Recently I've been working on a rename of
>> btrfs-tools to btrfs-progs, and I submitted at patch for
>> partman-btrfs. The #1 feature I'd like to work on is support for
>> installing to a btrfs subvolume. The #2 feature is btrfs-style
>> multiple device support in the installer.
>
> that would be nice. I think submitting patches to the BTS is the right
> way forward.
Ok, I'll open two bugs for the two features once I've identified all
the different parts that are affected. I've checked out a copy of
debian installer according to the instructions on the wiki.
>> I imagine #1 will be fairly easy. At this point in time I believe
>> that #2 should be limited to the raid1 profile, with mandatory
>> duplication of both metadata and data. Also, at this point in time I
>> do not believe that compression should be supported. Additionally,
>> I've read bug reports recommending displaying a notice in the
>> installer as to the experimental nature of btrfs. That would be #3,
>> but I'd be happy to re-prioritise it as #1
>
> I think optimally the subvolume to install on could be preseeded for #1
> and be able to reuse an existing btrfs volume. Similarly it'd be nice
> if one could provide some sort of list of subvolumes to create at
> installation time. (Although touching the partman receipe stuff for this
> might be a bit messy.)
To break down the #1 goal "add subvolume support":
a) Add ability to list existing, create, and delete subvolumes in partman-btrfs
i. study partman-LVM to learn how to do this
ii. alternatively, is partman-zfs in a state where I could use it as a base?
-- I noticed that partman-zfs is based off of partman-LVM, and
uses a lot of LVM terminology instead of ZFS
-- This surprised me, because I thought partman-modules were
independent from each other
b) Provide defaults for this support in a preseed file
i. study partman-LVM and example-preseed.txt to learn how to do this
ii. alternatively, is partman-zfs in a state where I could use it as a base?
c) How is "the subvolume to install on could be preseeded" distinct
from "provide...list of subvolumes to create"?
d) Tie into the module that manages fstab mount options, so a
subvolume created for /var gets mounted with
subvol=a_subvolume_for_var. This seems like the tricky part to me,
and afaik there is no equivalent in LVM or zfs. Would this work also
be limited to partman-btrfs, or are other modules/packages affected?
> I don't think there needs to be such a scary warnings on the kernel
> version stretch will ship with.
What version is this likely to be? 4.4.x? 4.6.x? From a
btrfs-perspective, I hope it's an LTS.
>> The goal is to ship a "safest possible configuration", to enable those
>> wish to use this next-gen filesystem to try it, while at the same time
>> reducing bug reports that are caused by the current behaviour. For
>> example one of the "killer features" of btrfs is the ability to dump a
>> subvolume as a FAR data stream. This doesn't work out-of-the-box on
>> Jessie, because the feature depends on a named subvolume.
>
> But right now it installs into "@", no?
According to debian-installer/packages/partman-btrfs/TODO, support has
not yet been added. I just installed
debian-stretch-DI-alpha5-amd64-netinst; it failed at package selection
after the base system was installed. I dropped to a shell to find out
how the btrfs volume was set up.
btrfs sub list /target
(no output)
mkdir /btrfs ; mount /dev/sda1 /btrfs
btrfs sub list -a /btrfs
(no output) <- if any subvolumes were created, they should have shown
up here, without exception
mount | grep btrfs
/dev/sda1 on /target type btrfs (rw,noatime,space_cache,subvolid=5,subvol=/)
/dev/sda1 on /dev/.static/dev type btrfs
(rw,noatime,space_cache,subvolid=5,subvol=/dev)
/dev/sda1 on /btrfs type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
subvolid=5 is the default subvolume, and subvol=/ further specifies
that this is not a subvolume. Unfortunately, like Jessie, it doesn't
install into "@". @ is an Ubuntu convention (apparently adopted by
OpenSUSE; stappers@stappers.nl moved this discussion to the thread
"New Thread old subject joining team").
Best regards,
Nicholas
Reply to: