done
4 Likes
I do the same as @Nachlese, fill all the disk space left with a big file full of zeros. Then, the size of the compressed backup image is much smaller. You don’t need to create the zero-filled files before each backup (I do may be twice a year). The zeros will remain there as long as you don’t overwrite them with other files.
1GB full of zeros is compressed to 1MB. 1GB full of random bytes is compressed to… the same 1GB.
2 Likes
Sometimes. For some specific reason.
Perhaps, but: see above:
there are (where) reasons.
Off the top of my head:
not real backups, but shrinking VM images …
Yes, I will.
Of course.
But that is part of the “problem”.
The tried and true and known to work procedures don’t apply anymore - and have to be replaced, re-learned.
It’s not a bad thing - but it is an obstacle.
It might not be “stinginess” in most cases - just simply:
the average Joe laptop user doesn’t look and doesn’t care - and: why should he have to?
And, suddenly:
boom - big problem
and then what?
It’s fairly easy to deal with - but very different to what average Joe might know …
3 Likes
Oh, and somewhere there should be a big notice with a skull and bones saying “if you clone a btrfs disk and your love your data, NEVER connect the original and the copy at the same time”.
1 Like
In the wikis I cannot find the command to delete a snapshot, neither in Btrfs_Maintenance#Clean_up_unused_snapshots nor in Btrfs#Releasing_snapshots. The wikis highly recommend removing unused snapshots, so it would be nice to have the command there.
There is a big notice! (without skull and bones)
Fortunately, this problem is a thing of the past
Current kernels no longer make the mistake of taking the two copies for a RAID (or something else), but instead assign a temporary UUID to the copy. This at least prevents anything bad from happening. 
done
It’s best to delete snapshots using the tool that created them.
- If you used Snapper to create them, delete them using Snapper.
- If you used Timeshift to create them, delete them using Timeshift.
- If you created them manually, delete them manually.
6 Likes
I suppose for those who are used to using chroot, it wouldn’t be more possible with btrfs?
Would it barely be useful for snapshots?
You can do a manual chroot of a btrfs file system, as mentioned in the super-useful description of restoring a broken grub set-up:
4 Likes
With respect to choosing BTRFS in Calamares during initial install, it was also dead easy before the recent change. As I understand it, the main difference is that with Manjaro 25 (Zetar) ISOs, BTRFS is now the default choice.
I’m looking forward to using BTRFS myself when next I have opportunity to start from scratch. In the meantime, I continue to use EXT4 which has proven equally resilient in my environment.
I recall with some amusement the many “nay sayers” at the time that HFS+ was unilaterally replaced with APFS. Given time, most everyone eventually recognised the benefits, but it was a tough sell for some.
People often don’t like change;
try not to scold them for it too much. 
Regards.
5 Likes
If you want to switch to btrfs,
there’s no reason to wait ;-). You could simply convert your ext4 to btrfs!
When I started using btrfs, there was no way to install it with btrfs. So I installed it with ext4 and then converted to btrfs.
To make it bootable again, you’ll have to tweak a few things. But you’re not new to Manjaro. 
You can do it.
Keywords that come to mind are fstab, grub, grub.cfg, mkinitcpio. If you search, you’ll find every single step documented here in the forum
I asume, you know how to make a backup
1 Like
I intend waiting until I can acquire new hardware for the purpose. I multi-boot this particular machine with several operating systems including Manjaro, and use rEFInd as the primary bootloader.
A UEFI filesystem driver for BTRFS is needed for rEFInd to access the Linux kernel. An EXT4 filesystem driver is included by default, but I haven’t had opportunity to test the available BTRFS drivers. Yes, I could use a separate EXT4 partition for /boot, but I’d like to avoid that.
There will be plenty of time to try out different BTRFS configurations on VM in the meantime.
1 Like
If this becomes available, please let me know. It sounds interesting to me.
Well, they have been available for a long time, but some of them seem to disappear and re-emerge in different places. It’s difficult to keep track of specific UEFI drivers one might be interested in.
That said, the following site has been stable for years; and they are updated fairly regularly; though, I’ve only used their ext4 and hfsplus drivers so far in production.
Naturally check them after download to make sure you get the actual drivers and not a mess of html.
1 Like
me too.
1 Like
I’ve done that.
And there’s nothing wrong with that, either. It can help workaround some possible issues with the BTRFS/GRUB combination, such as those you mentioned recently.
I’ll play around with btrfs_x64.efi in a VM when I have a free day to focus. I do like the idea of not having to create a separate /boot partition just to avoid possible scenarios.
Again, use of this driver is only in relation to refind.
1 Like
As a side note: all file systems have their place; there’s no good or bad. The user decides which file system is suitable for their purposes.
My wife uses xfs, not because she needs it, but because we both weren’t paying attention during the Calamares installation!
Since she’s not considering changing the partition size, it’s staying as it is.
One thing I like about BTRFS is the handling of available space - it reminds me of APFS in that unused space is shared across all partitions.
This is especially handy when setting up a new installation as one no longer has to second-guess how much space to allocate for each partition.
Of course, some people just use default settings during install (“click, click, click”) and possibly never create a partition in their lives; for those cases that benefit is lost.
2 Likes
From my 2 year experience on stable and polls, somewhere around 90% is the redline. Above that - all the problems are from poor maintenance. Somewhere around and below 85% means the update is objectively “bad”, like the developers forgot to describe a required manual action in the known issues to prevent a major problem (nvidia, grub, pacnew shell, plymouth, fctix and similar).