BTRFS made easier to setup during installation

[slim-salm]

Good day,
Forgive me if there is already a thread open for this idea.
I know there is a way to install Linux mint on a BTRFS filesystem, but it is a bit advanced for a newcomer.
I have been running BTRFS with zram for my swap now for nearly 2 years on my laptop and the seamless restore is really nice to have, not even to mention the COW functionality.
Although EXT4 is the default, would it not be nice to have a default pre-configured option for a BTRFS that will work out of the box without going in knee deep into the setup doing things like creating subvolumes @ and @home?

Maybe also add a additional feature to support more subvolumes for timeshift, should advanced users desire to have more subvolumes for whatever reason?

I can really see that business would easily be able to make use of linux mint systems as additional workstations with additional toolsets like versioning with BTRFS

[jakjasie1]

I agree, this sinplifies e.g snapshots in Timeshift. Could even enable them by default when installed with BTRFS, since they don't occupy a lot of space in BTRFS. I believe a good way to implement this is to simply add a switch in the installer, like some other programs do.

[Fantu]

This tutorial can help with the use of btrfs on mint in some cases: https://github.com/orgs/linuxmint/discussions/549

[slim-salm]

I know there are many tutorials to set it up. The point I try to make is to make it seamless like it is set up for EXT4 filesystem.

[mtwebster]

We wouldn't recommend btrfs for new users at this point - if someone thinks they need it it's easy to use the 'Something else' option to make and assign the partitions themselves.

My personal experiences have all started great - I love the snapshot capabilities, but have ended with 'where's my disk space and how do I get it back?' - just google 'btrfs lost disk space'. That's not something a typical user should ever have to worry about running into.

[slim-salm]

I do somewhat agree that it should not be recommended for beginners, but I also think it is for the user to decide. The developer should not be gatekeepers.. I didn't say BTRFS should be the default, it can stay at the advanced section, but all I ask is to make the BTRFS setup as seamless as what EXT4 is, thats it, nothing more, nothing less.

On the flip-side I also had problems with EXT4 where it said the disk is full, but it was not full, later after a format I learned the hard way it had to do with inode limit that is reached if I remember the term correctly, as a new user, you also don't want to deal with such problems as well...

[mortim]

We wouldn't recommend btrfs for new users at this point - if someone thinks they need it it's easy to use the 'Something else' option to make and assign the partitions themselves.

My personal experiences have all started great - I love the snapshot capabilities, but have ended with 'where's my disk space and how do I get it back?' - just google 'btrfs lost disk space'. That's not something a typical user should ever have to worry about running into.

You're right but it could be nice if Mint sets up properly the swap memory within the BTRFS filesystem because the special features (especially CoW) of this filesystem does not allow swap by default.

[slim-salm]

If it cannot be done, that is fine, if you don't want to do it that is fine as well.
But just because of issues such as "lost disk space on BTRFS" shouldn't repel you from using it. The probability is when someone does choose to make use of BTRFS, they already made up their mind that they want to try it. But again, it is a idea, I am no developer, but I do like cool technologies like ZFS an BTRFS.

[Fantu]

I have been using btrfs for about ten years now at work on servers and for a few years also on some disks in personal use.
It has both pros and cons and is not optimal for any use (I still use ext4 in most cases).
It seems stable and reliable to me, apart from the well-known problems with raids with parity (where there is a risk of data loss and is better avoid them), in fact I only use raid 1 and in some cases DUP profile (for double copy even on the same disk).
raid 1 or DUP together with data checksums and self-repair guarantee an excellent advantage for integrity, in some cases more than that of hardware raid and software raid with mdadm, with DUP on single hdd also to limit problems such as those given by possible defective sectors.
It requires some occasional maintenance operations more than ext4, the space problems I have seen are mainly due to the management of snapshots and not the fault of btrfs itself (there can easily be similar problems even using zfs and lvm snapshots) even if in part it keeps a little too much space reserved and can require the "balance" to solve.
There is also less performance (especially on hdd), and mainly because of the cow (which can be deactivated, but you would lose most of the features/advantages), so in certain cases I think it is better not to use it.
I think having it better integrated even if not predefined would be very useful.

[slim-salm]

I can imagine the performance loss on normal hdd, but is it that noticeable on ssd/nvme drives? What will a better integration be for you?

[Fantu]

It's not a quick and easy answer, unfortunately I haven't had time yet (and I don't know when I will have) for a good and in-depth analysis for the desktop part what is needed for a good integration.

Performance issues are mainly on HDD and with growth of the number of snapshots can be very significant, as seen for example in several backup disks on virtualization servers (used only for backup disks and history via snapshots, faster and with less space consumption).
The "problem" remains even if you keep old snapshots deleted (leaving a few) and after 1-2 years you notice a latency in many operations, even mounts.
I suppose defragmentation can help, but I avoid it because it loses the space-saving advantage of cow snapshots (which do not replicate the same data), with defragmentation when you move the data of a snapshot that is the same in others (not taking up space) it duplicates taking up more space.
In SSDs, however, defragmentation obviously should not be used, in general it is not necessary and it shortens the life of the disks (due to the numerous additional writings).
I have rarely used the balance, many seem to recommend it as a regular maintenance operation, but it doesn't seem like a good idea to me (I think should be used only when necessary or more rarely "as maintenance"), it takes a long time and with intensive resource usage, in the case of SSDs here too you have to consider that with many more writes the life is shortened.
If you don't use snapshots (or if you only make a temporary one occasionally to use for external backups) and you use it as a storage/fileserver to have control over data integrity and possible self-repair (with dup and raid profiles) as in several of my cases both on servers at work and personal ones then I haven't seen any particular performance problems, not even on hdd.
I've seen a few more performance issues on Windows (I use it with WinBtrfs) but I only use it for backup disks there.
So it is not relevant for me, but if someone wants to use it for other uses on Windows (or even windows, for example in dual boot) it could be very relevant.
!!! IMPORTANT: on Windows there are other limitations and possible problems, use caution and if you use both windows and Linux I recommend you always do any maintenance operations on it only from Linux.

In these weeks I'm evaluating to increase its use on the new virtualization servers, only for the root and not the vm disks, on the old ones based on Debian stable I used it (and still use) without snapshots for many years, "only" for integrity control and self-repair, on the new server based on Proxmox instead I want to use it more with snapshots and any fast restores if necessary.
With Debian stable the problems are very rare and almost only in the initial testing phase while with Proxmox unfortunately several main components (such as kernel and qemu) are near "rolling release" and the problems are more frequent, in particular regressions when updating, which is why I would like to use snapshots for any very fast restores.
I don't know yet if I will have enough time to contribute a small part with the integration, for example for the official grub-btrfs package on Debian, it would be necessary to do/test also the desktop part with timeshift to do it properly and completely.
On the server part, I excluded timeshift from the start because it is not possible to use it only via CLI and without installing the graphical part.