package: debian-installer
severity: wishlist

 It's enhancement proposal, not bug report. Now Debian system cannot use
 whole btrfs power, but we can improve it.

 debian-installer can format disk with btrfs now, but it is NOT appropriate
 setting with btrfs. We can just format partion with btrfs but cannot create
 btrfs "subvolume" at that time.

 Subvolume is a bit special idea, you can slice one btrfs partion to some
 subvolume and can set quota for each subvolume, also mount directory and
 get snapshot for each.

 So, I'll propose debian-installer to add btrfs subvolume setting menu or
 add subvolume setting like SUSE by default.

 For detail, see Btrfs Wiki page
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-subvolume


 Well, for exapmle, openSUSE's installer (YaST2?) creates defalut partition
 as btrfs and below subvolumes by default.
------------------------------------------------------------------------------
@/boot/grub2/i386-pc
@/boot/grub2/x86_64-efi
@/home
@/opt
@/tmp
@/usr/local
@/var/crash
@/var/lib/libvirt/images (option "no copy on write")
@/var/lib/mailman
@/var/lib/mariadb (option "no copy on write")
@/var/lib/mysql (option "no copy on write")
@/var/lib/named
@/var/lib/pgsql (option "no copy on write")
@/var/log
@/var/opt
@/var/spool
@/var/tmp

 and default / subvolume.
------------------------------------------------------------------------------

 - Snapshotting is targeted to default / subvolume and whole system except
   above subvolumes. Separating some directories are very important for btrfs
   snapshot. It makes easy to rollback to previous snapshot image without any
   losing data.

 - And, "no copy on write" mount option is important for DB systems
   for performance.

 - I'm not sure why they separate /boot/grub2/i386-pc and x86_64-efi

 If it is hard to add creating subvolume menu, just follow SUSE's decision
 is worse.


 Some people says "btrfs is not stable", but SUSE and Oracle support it as
 commercial support. Some features like RAID5,6 is not stable as it says(*),
 but upstream developer Chris Mason says "Aging" state in Facebook(*). So
 it's worse to treat btrfs as sane choice and release its power as possible,
 IMO.


 *) https://btrfs.wiki.kernel.org/index.php/Status
 *) https://youtu.be/W3QRWUfBua8?t=17m51s

Hi,

 More SUSE btrfs setup information is
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_snapper_setup.html

On Mon, Oct 10, 2016 at 09:22:14AM +0900, Hideki Yamane wrote:
[...]
[...]

Hi Hideki,

Thank you for the reminder!  I've been planning to do this work for
quite some time.  (
https://lists.debian.org/debian-boot/2016/04/msg00277.html )

So far, the plan is to default to simple @rootfs and @home subvolumes,
because I've read that backing up OpenSUSE systems is cumbersome with
all of those subvolumes, and also because of the KISS principle; That
said, one will have the flexibility to choose this style, if desired.
I absolutely agree that, for example, there needs to be a mechanism in
place to allow configuration of a separate subvol for /var/www and
/var/database_of_choice at the time a Debian system is installed.

The second half of better Debian btrfs support is better
documentation. ( https://wiki.debian.org/Btrfs )  To the best of my
knowledge, the following is still applicable:
https://btrfs.wiki.kernel.org/index.php/Mount_options

As a consequence, per-subvolume btrfs mount options set in the
installer would not be honoured, because the fstab mount option for
@rootfs are applied to all other subvolumes .  The three workarounds
are 1) Create a separate physical partition for @nodatacow_subvol.  2)
chattr +C the mountpoint, relying on the application's own COW and
checksumming implementation.  3) Disable the application's COW and
checksumming implementation and rely on btrfs'.

I'll try to having something ready for testing by Oct 24th, with a
hard deadline of Nov 1st.

Cheers,
Nicholas

On Mon, Oct 10, 2016 at 09:22:14AM +0900, Hideki Yamane wrote:
[...]
[...]

Hi Hideki,

Thank you for the reminder!  I've been planning to do this work for
quite some time.  (
https://lists.debian.org/debian-boot/2016/04/msg00277.html )

So far, the plan is to default to simple @rootfs and @home subvolumes,
because I've read that backing up OpenSUSE systems is cumbersome with
all of those subvolumes, and also because of the KISS principle; That
said, one will have the flexibility to choose this style, if desired.
I absolutely agree that, for example, there needs to be a mechanism in
place to allow configuration of a separate subvol for /var/www and
/var/database_of_choice at the time a Debian system is installed.

The second half of better Debian btrfs support is better
documentation. ( https://wiki.debian.org/Btrfs )  To the best of my
knowledge, the following is still applicable:
https://btrfs.wiki.kernel.org/index.php/Mount_options

As a consequence, per-subvolume btrfs mount options set in the
installer would not be honoured, because the fstab mount option for
@rootfs are applied to all other subvolumes .  The three workarounds
are 1) Create a separate physical partition for @nodatacow_subvol.  2)
chattr +C the mountpoint, relying on the application's own COW and
checksumming implementation.  3) Disable the application's COW and
checksumming implementation and rely on btrfs'.

I'll try to having something ready for testing by Oct 24th, with a
hard deadline of Nov 1st.

Cheers,
Nicholas

a fix in this case because by default it mounts the top-level, which
means that the actual chroot is one level down. Although I guess setting
the default subvolume id to the one of whatever you call @rootfs should
also fix this.

Kind regards
Philipp Kern

a fix in this case because by default it mounts the top-level, which
means that the actual chroot is one level down. Although I guess setting
the default subvolume id to the one of whatever you call @rootfs should
also fix this.

Kind regards
Philipp Kern

[...]

Hi Philip,

So sorry for the delay.  Life stuff that my plan couldn't accommodate
for :-(

Which rescue mode, and where?  Please tell me so I can fix it!  From
what I've read, setting a default subvolid != 5 was explored by other
distributions, and abandoned.  As I hadn't received any feedback from
debian-boot@, and it seemed like development has shifted to providing
translations only, I thought that a minimal change that didn't require
translation would be more appropriate.  From this proposed default
configuration, in single user mode, rootfs' partition can be mounted
without subvol=@subvolume somewhere like /btrfs-admin and subvols can
be created as children of subvolid 5 and peers to @rootfs (eg: @var),
then you replicate the data from /btrfs-admin/@rootfs/var, and finally
edit fstab and mount the new /var subvolume, go multiuser or reboot.

I would very much appreciate it if you would take a look at it.  I
understand it needs to be rebased ;-)
https://anonscm.debian.org/cgit/d-i/partman-btrfs.git/log/?h=proposed

Concerning the naming of the rootfs subvol, is there something you
would prefer?  I've since learned that LXC's btrfs backend follows the
Fedora/CentOS/RedHat convention of a simple "rootfs" albeit by nesting
it in whatever subvolume /var/lib/lxc belongs to.

I plan to keep working on this even if it's now too late for Stretch's
initial release!

Cheers,
Nicholas

[...]

Hi Philip,

So sorry for the delay.  Life stuff that my plan couldn't accommodate
for :-(

Which rescue mode, and where?  Please tell me so I can fix it!  From
what I've read, setting a default subvolid != 5 was explored by other
distributions, and abandoned.  As I hadn't received any feedback from
debian-boot@, and it seemed like development has shifted to providing
translations only, I thought that a minimal change that didn't require
translation would be more appropriate.  From this proposed default
configuration, in single user mode, rootfs' partition can be mounted
without subvol=@subvolume somewhere like /btrfs-admin and subvols can
be created as children of subvolid 5 and peers to @rootfs (eg: @var),
then you replicate the data from /btrfs-admin/@rootfs/var, and finally
edit fstab and mount the new /var subvolume, go multiuser or reboot.

I would very much appreciate it if you would take a look at it.  I
understand it needs to be rebased ;-)
https://anonscm.debian.org/cgit/d-i/partman-btrfs.git/log/?h=proposed

Concerning the naming of the rootfs subvol, is there something you
would prefer?  I've since learned that LXC's btrfs backend follows the
Fedora/CentOS/RedHat convention of a simple "rootfs" albeit by nesting
it in whatever subvolume /var/lib/lxc belongs to.

I plan to keep working on this even if it's now too late for Stretch's
initial release!

Cheers,
Nicholas

rescue-mode is in [0]. That presents you with a menu where you can
select local root filesystems. That should somehow DTRT instead of
mounting the top-level btrfs filesystem with the root filesystem being
below. I suppose it'd be also ok to mount it as-is, as long as the shell
is spawned in the right place. (Although that might be surprising.)

The mode is triggered by passing "rescue/enable=true" on the kernel
command-line. d-i ships with boot menu items that do this.

Kind regards
Philipp Kern

[0] https://anonscm.debian.org/cgit/d-i/rescue.git/tree/

rescue-mode is in [0]. That presents you with a menu where you can
select local root filesystems. That should somehow DTRT instead of
mounting the top-level btrfs filesystem with the root filesystem being
below. I suppose it'd be also ok to mount it as-is, as long as the shell
is spawned in the right place. (Although that might be surprising.)

The mode is triggered by passing "rescue/enable=true" on the kernel
command-line. d-i ships with boot menu items that do this.

Kind regards
Philipp Kern

[0] https://anonscm.debian.org/cgit/d-i/rescue.git/tree/

Hi Philipp,

Thank you for the clarification, and sorry for my tardy reply.

Oh, there!  I had already checked that out in
debian-installer/packages/rescue.  :-) From what I gather, DTRT looks
something like one of the following:

1. Use existing choose partition menu
  * select partition menu
  * test if selected partition is a btrfs volume
    -  if there are no subvolumes, use present behaviour
  * if subvolumes exist
    - install btrfs-progs udeb
    - use btrfs subvol list to read subvols
    - present a menu

How is this currently handled for LVM?  There is very little code in
"rescue" itself, and I haven't yet managed to figure out how
everything fits together.

2. Alternatively, duplicate the existing LVM code, then modify it for
   btrfs.

If you could point me to whatever 'rescue' ties into for LVM support I
would be very grateful!  From what I've gathered so far, "rescue"
dependency on the btrfs application is provided by the btrfs-progs udeb and
not through initramfs

Cheers,
Nicholas

Hi Philipp,

Thank you for the clarification, and sorry for my tardy reply.

Oh, there!  I had already checked that out in
debian-installer/packages/rescue.  :-) From what I gather, DTRT looks
something like one of the following:

1. Use existing choose partition menu
  * select partition menu
  * test if selected partition is a btrfs volume
    -  if there are no subvolumes, use present behaviour
  * if subvolumes exist
    - install btrfs-progs udeb
    - use btrfs subvol list to read subvols
    - present a menu

How is this currently handled for LVM?  There is very little code in
"rescue" itself, and I haven't yet managed to figure out how
everything fits together.

2. Alternatively, duplicate the existing LVM code, then modify it for
   btrfs.

If you could point me to whatever 'rescue' ties into for LVM support I
would be very grateful!  From what I've gathered so far, "rescue"
dependency on the btrfs application is provided by the btrfs-progs udeb and
not through initramfs

Cheers,
Nicholas

Ah...the logic is in debian/rescue-mode.postinst; I had assumed it
would be elsewhere.  I'll take some time to study this thoroughly, and
to do a VM install and rescue to see how the LVM case works.  If you
know if it's closer to (1) or (2) in my last email.

Is Feb 5th (Full freeze) the final deadline for this work?  Deadline
being, it needs to have been submitted to ftp-masters before then.

Cheers,
Nicholas

Ah...the logic is in debian/rescue-mode.postinst; I had assumed it
would be elsewhere.  I'll take some time to study this thoroughly, and
to do a VM install and rescue to see how the LVM case works.  If you
know if it's closer to (1) or (2) in my last email.

Is Feb 5th (Full freeze) the final deadline for this work?  Deadline
being, it needs to have been submitted to ftp-masters before then.

Cheers,
Nicholas

Hi,

Update: I've learned that Debian Installer work needs to be completed
about four months before the freeze.  As it looks like I'll be swamped
with work for the next month or two I'm unsetting myself as owner.

If no one finishes the work in time for buster freeze I'll resume work
sometime this spring.  It's not nearly as simple as I'd hoped it would
be.

Cheers,
Nicholas

Hi,
https://salsa.debian.org/installer-team/partman-btrfs/merge_requests/1

I decided to leave configuring @home up to the user, because the user
may wish to mount /home using another block device, possibly on a
non-btrfs volume.

Also, adding full-fledged btrfs subvolume configuration (eg: forking
partman-lvm) to DI will require a comaintainer.  The bus-factor is too
high for me to do it alone.

Would you like to take care of rescue-mode or shall I?


Cheers,
Nicholas

Hi, has there been any news on this in the last few years gone by?

I've been using btrfs on debian for about ten years now, I use it both
personally on some data volumes and backups and at work on servers for
backups, data and root of some servers (but without snapshots for each
on the root volumes).

I'm about to try to start using it seriously also with roots and
snapshots for my new workstation and on future servers but I'm finding
that the support on debian is unfortunately very limited, requires more
time and additional operations and also difficult to reuse existing
volumes while maintaining the data.

the ability to manage btrfs subvolumes at installation would be a great
thing that would allow having an installation with the necessary
subvolumes in a much simpler and faster way and also to use existing
volumes (without having to move the content, create temporary partitions
etc...)

another good thing for server will be also RAID support, I saw this
related to RAID1 opened ten years ago here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748724

another useful thing, would be to have some options that can be set
during installation, mainly compression (being able to choose whether to
enable it and with which option), you can easily convert it afterwards
but these are additional operations. Other can be for example set
single/duplicate profile for data/metadata.

In any case thanks for your work and thanks for the minimal subvolume
support that was added.


in case you can't make support subvolumes settable in the installer for
Debian 13 could it be quite simple and fast to at least have a choice to
create only minimal (like now) or "extended" subvolumes?

for extended I think can be added for example:

- /var/log: both to keep them for debugging in case of root rollback and
for the numerous writes on them (which would unnecessarily impact root
snapshots)
- /var/cache and /var/tmp: contain temporary files and caches. for don't
waste space on root snapshot.
- /var/spool: Contains data that is awaiting some kind of later
processing, such as mail, mail queues, printing, printer spool, and so
on. To prevent the loss of mail, printing, and spool data following a
rollback.

there are also other that can be specific to some usage, I don't know if
good have them by default on extended, for example:

- /var/lib/libvirt/images: The default location for libvirt-managed
virtual machine images. So that virtual machine images are not replaced
with older versions during a rollback.

- /var/www: Web server directory. To keep hosted web server data
separate and prevent data loss during system root rollbacks.

have more subvolume like these easy/fast on install I think will
decrease issues for many users that will use root snapshot and rollback,
without good knowledgedoing them manually after the installation


thanks for any reply and sorry for my bad english