Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Control: owner -1 !

Hi,

On Sun, Oct 30, 2016 at 02:21:39PM +0100, Philipp Kern wrote:
> On 10/11/2016 11:40 PM, Nicholas D Steeves wrote:
> > 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; [...]
> 
> FWIW, given that I just encountered this myself: rescue(-mode) will need
> 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.
> 

I've submitted a tested MR at:
  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


signature.asc
Description: PGP signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Control: noowner -1

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


signature.asc
Description: PGP signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

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


signature.asc
Description: Digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Hi Philipp,

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

On Wed, Jan 04, 2017 at 12:04:09AM +0100, Philipp Kern wrote:
> On 12/19/2016 05:49 AM, Nicholas D Steeves wrote:
> > 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.
> 
> 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/
> 

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


signature.asc
Description: Digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Philipp Kern]

On 12/19/2016 05:49 AM, Nicholas D Steeves wrote:
> 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.

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/



signature.asc
Description: OpenPGP digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

On 30 October 2016 at 07:21, Philipp Kern  wrote:
> On 10/11/2016 11:40 PM, Nicholas D Steeves wrote:
>> 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;
[...]
>
> FWIW, given that I just encountered this myself: rescue(-mode) will
> need
> 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.

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


signature.asc
Description: Digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Philipp Kern]

On 10/11/2016 11:40 PM, Nicholas D Steeves wrote:
> 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; [...]

FWIW, given that I just encountered this myself: rescue(-mode) will need
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




signature.asc
Description: OpenPGP digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Nicholas D Steeves]

Control: owner -1
Control: tags -1 pending

On Mon, Oct 10, 2016 at 09:22:14AM +0900, Hideki Yamane wrote:
[...]
>  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.
[...]

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


signature.asc
Description: Digital signature

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Hideki Yamane]

Hi,

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


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Hideki Yamane]

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


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane