#2085 Issue `closed`: Enhance btrfs_subvolumes_setup_generic() to make it work everywhere.¶

Labels: enhancement, no-issue-activity

jsmeix opened issue at 2019-03-15 13:04:¶

This is a follow-up of
https://github.com/rear/rear/issues/2067
which is fixed for its particular use case
since https://github.com/rear/rear/pull/2079 and the subsequent
https://github.com/rear/rear/pull/2080 were merged.

But in general btrfs_subvolumes_setup_generic()
needs some enhancements to make it work everywhere, see
https://github.com/rear/rear/pull/2080#issuecomment-472448686
and subsequent comments.

In particular the curent btrfs_subvolumes_setup_generic()
makes diskrestore.sh fail on older systems where
btrfs subvolume set-default needs two arguments, see
https://github.com/rear/rear/pull/2080#issuecomment-472458530

github-actions commented at 2020-06-28 01:33:¶

Stale issue message

OliverO2 commented at 2020-11-09 10:23:¶

@jsmeix
The remaining underlying issue (https://github.com/rear/rear/pull/2080#issuecomment-472458530) has been resolved by PR #2119 on May 2, 2019, which is part of ReaR 2.6.

It seems like we could transition to btrfs_subvolumes_setup_generic by default now. The next step would then be to remove the duplicate SLES implementation.

jsmeix commented at 2020-11-09 13:33:¶

As far as I remember my latest tests on SLES with its default btrfs structure
failed with btrfs_subvolumes_setup_generic so we cannot remove
the special SLES implementation.
I won't spend much time on this issue.
The special SLES implementation works for the special SLES default btrfs structure
so why change something that works?

What can be enhaced (if needed) to make btrfs steup work better
out of the box on various different Linux distributions is the part to
# Call the right btrfs_subvolumes_setup_* function for the btrfs filesystem ...
in layout/prepare/GNU/Linux/133_include_mount_filesystem_code.sh
https://github.com/rear/rear/blob/master/usr/share/rear/layout/prepare/GNU/Linux/133_include_mount_filesystem_code.sh#L76

None of the BTRFS_SUBVOLUME_GENERIC_SETUP
and BTRFS_SUBVOLUME_SLES_SETUP arrays are described in default.conf
so we are free to andapt and enhance things as needed (if needed).

I think via the code in layout/save/GNU/Linux/230_filesystem_layout.sh that
# Save the updated BTRFS_SUBVOLUME_SLES_SETUP array variable ... into the rescue.conf file
https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh#L514
the special SLES implementation is enforced where needed
so that using the generic code by default should not break things on SLES.

At some time in the future a really generic implementation would be done via
https://github.com/rear/rear/issues/2510
which is where I spend now most of my time - at least for now to do some research.

OliverO2 commented at 2020-11-09 14:52:¶

@jsmeix

As far as I remember my latest tests on SLES with its default btrfs structure
failed with btrfs_subvolumes_setup_generic

True some time ago, but this was fixed since.

so we cannot remove the special SLES implementation.

To me it looks like we can. The "generic" implementation should work just fine on any configuration of SLES.

The special SLES implementation works for the special SLES default btrfs structure so why change something that works?

btrfs_subvolumes_setup_generic is complete and so much simpler. You wrote in https://github.com/rear/rear/pull/2079#issuecomment-471958783:

Of course the goal is to have only one implementation that is functionally complete and simple and straightforward.
btrfs_subvolumes_setup_generic fixes #2067 (Restoring Btrfs file system fails if a snapshot has been used for rollback). A non-working restore is a worst-case-scenario, which could happen anytime to anyone using Btrfs. Currently, ReaR out of the box comes without a fix for this issue. Possibly no one knows the secret configuration change required to address this.

I cannot say how this relates to #2510. I guess we just have to see what the design will be. But it looks this will take some time. In the meantime ReaR should not ship with a known restore defect. Btrfs slowly but steadily seems to gain more traction, as even Fedora now defaults to Btrfs.

[Export of Github issue for rear/rear.]