Btrfs installation is sub-optimal

[KerimG]

When using btrfs Cnchi should create a default subvolume. I.e. when using btrfs for a separate /home partition, Cnchi shouldn't just put the home folders in the root of that, but first create a subvolume and then put them in there. Without using a subvolume you can't really use btrfs to its full potential. It's a bit of a PITA to have to do it manually afterwards.

/etc/fstab has to be modified accordingly, as in mount the created subvolume instead of the partition itself.

[thagabe]

Any update on this? Will it be on v0.16 or v0.18?

[karasu]

To be honest, nobody is working on this at this moment. We feel there are more pressing issues at this moment, sorry.

[thagabe]

@karasu How about now?

[aardbol]

I was looking into adding better BTRFS support to Cnchi after all my research and testing (result at: https://blog.wheredoi.click/installing-antergos-linux-with-a-btrfs-filesytem-and-subvolumes-with-uefi/) to make full use of BTRFS features in Antergos.

Unfortunately there's no developer documentation and explanations in the code are also very limited. The different folder structures in the different branches added to the confusion. Even my topic at the forums was left unanswered. I understand that the devs have a lack of time, but since only trying to figure out the code was taking too much of my time, I quit my ambition to make Antergos <3 BTRFS.

[karasu]

@IsaakGroepT I would be more than glad to help you doing this, but now I don't have the time (as you have guessed).

I'll have more time in June and onwards. Please, don't give up on this (and on us).

Cheers!

[aardbol]

@karasu Thanks for replying. It's good to know that's you're interested in this feature and are willing to assist. A big part of my fear was that I was going to do all the trouble to understand the code, develop the features and have it maybe rejected.

I'm not giving up on this and will wait for the right moment (if I didn't start in advance yet). And certainly I don't give up on you guys. Do know that I really appreciate what you're doing and have all understanding for the lack of time that you have.

[aardbol]

So guys, a little update. I've started planning my strategy for a good BTRFS implementation in Cnchi and Antergos. This is the first draft (that could be updated anytime):

https://greatatlas.stackstorage.com/s/eKCvVdzPKntns8w

[jose-sanchezm]

Please, take into account already stablished conventions by backup tools like timeshift https://github.com/teejee2008/timeshift and Snapper http://snapper.io which require the existence of a subvolume @ at root level and @home for home (if it's not in a different physical partition). Ubuntu, OpenSuse and Manjaro installers use this convention when installing over a btrfs partition so it would be useful if Cnchi did the same.

[aardbol]

Thanks for your input. As much as I found out about it, the @ naming of the subvolumes is just aesthetics and don't offer any advantage over just naming the subvolumes root and home. I rather think it's others copying the way SUSE does it, rather than it being a convention. And as Antergos follows the Arch way of doing things, and the Arch wiki doesn't mention anything about it, I would just limit myself to doing it the Arch way, meaning no @s.

My documentation (and my blog) mention a subvolume for the root path, so that will be implemented for sure, otherwise it would be an incomplete BTRFS implementation too.

I'm all for snapper and for implementing it, as it makes managing snapshots much easier. Your argument about it requiring a home and root subvolume isn't true though, because you can create a configuration for any subvolume with it and just manage snapshots for that subvolume. I'm not for timeshift as it's a Gnome application (and installs pesky dependencies). As Antergos doesn't focus on Gnome alone (and I'm a KDE user), I prefer to implement DE neutral GUI tools. However, maybe it would be interesting to implement it for the Gnome DE eventually.

[jose-sanchezm]

I understand the need to be neutral and not use a specific layout because other distributions do it but those two tools are very useful to get a resilient system and this is specially important in a rolling release where any update can break it and make it unbootable. Could it be possible to extend cnchi so it either lets you choose one model or even better, it allows you to create arbitrary subvolumes and install to one of them as root (and home) filesystem?

[aardbol]

The goal is to offer as much customizability as possible, with a standard subvolume setup available. In that way I'll copy the SUSE way. But still, I don't see any really advantage by offering the GUI tool in the starting phase of the BTRFS implementation. Snapper already provides all the features to make snapshots comfortable. I do like the automatic snapshot schedule feature of Timeshift though. I'd like to see such a feature implemented too, next to hooks that activate on certain actions.

Just know that my intention is to provide the CLI for management. If there's more room for GUI stuff, then I'll cross that bridge at that time. I do like GUIs, but implementing those take extra time, while I want Antergos to <3 BTRFS first with a good implementation.

[aardbol]

Hi karasu,

To come back to this, how would you advice me to work on the better btrfs support. Like, which branch do I need to work on (master?) and where would you like to see the btrfs implementation applied to (as in, which files should my focus go to?). Since there's so much difference between the stable and dev branches, this info could save me plenty of time.

Do you have any tips on which functions or other code I need to keep in mind developing the btrfs setup, that I could reuse to avoid reinventing the wheel? Other tips are also helpful

I'd like to take a go at it soon, revise the plan draft I made before and make a proposition with a PR. I'm thinking of just adding an extra line under the zfs setup where people could choose for a btrfs setup. Before I start, I'm going to update you with a revised plan where I described my ideas so I can take into account people's feedback

[karasu]

@IsaakGroepT it's great you're committed to do this! Let's see...

which branch do I need to work on (master?)

Nope, work on 0.16.x branch. It's the current development one. Or even better, create a new branch from that one, something like 0.16.x-btrfs

Do you have any tips on which functions or other code I need to keep in mind developing the btrfs setup, that I could reuse to avoid reinventing the wheel?

I would check auto_partition.py to see how the hard disk is prepared in the automatic methods. ZFS is done differently, in zfs.py (and uses methods from zfs_manager.py).

I'm thinking of just adding an extra line under the zfs setup where people could choose for a btrfs setup.

That would be perfect. You need to add the option in the ask.py page (to add the widget in the GUI you need to edit ask.ui).

Before I start, I'm going to update you with a revised plan where I described my ideas so I can take into account people's feedback

OK!

[aardbol]

It's been a while that this feature got any activity, while I mentioned I wanted to work on this. Unfortunately, I still have my hands full until at least June. I'm working on my thesis and also other assignments next to the almost full time job that I'm doing, so I can't really focus on this right now. If I did, the result wouldn't be of decent quality anyway.

If the devs don't consider adding awesome btrfs support to Cnchi in the meantime, I'll look into asap after finishing my studies this year.

[karasu]

@IsaakGroepT tbh, we have our hands full just fixing broken things, so we are not thinking about working on this in the near future.

We would be more than grateful if you can consider working on this when you have the time.

Cheers!