Why did Manjaro switch to btrfs. I didn’t pay attention on install as it has always been ext4, well until now anyways.
And since it is btrfs who does timeshift back up to an ext4 file system.
It was included in the February announcement of the review release (a.k.a. pre-release) of Manjaro 25.0, which did request user feedback on changes such as the switch to btrfs
:
Well I an using the new/fresh Manjaro and now I see what you meab about grub entries.
Just that it came a a bit of a surprise of the switch to btrfs and I can only assume that Timeshift has indeed been modified to do backup from btrfs to ext4 on external disks.
To sum it up, the system is fine. no problems.
That is good to read. I last installed Manjaro at the end of 2023 when I bought my new mini-PC, and it has been trouble-free since then. However, I have been feeling a little pensive about whether I should change from ext4
to btrfs
if I ever need to reinstall my system, or when I buy my next PC (probably some time next year).
Every time I see that another Manjaro user is not experiencing any real issues with using btrfs
, I feel a little less anxious about making the ext4
→ btrfs
switch.
I don’t know if it’s psychological thing or not, but the system seems to be a bit more peppy. Probably some mind-thingy I guess.
Just speculating - it is a selection - yes it is now default - nonetheless - it is a selection you have acknowledged - so how is it a surprise?
Unless of course you don’t actually look at the screen - just clicking next, next, next, next, done - ups.
Btrfs with Snapper?
One more reason for me to try Manjaro.
https://manual.siduction.org/sys-admin-btrfs-snapper_en.html
I’ve been running BTRFS with snapper for the past six months or so and it’s been working flawlessly. Pair it with Btrfs-Assistant and you get an easy-to-use GUI as well.
I’ve never had to use it, but I know that it works and how it works.
For a distribution that wants to be user-friendly, Btrfs with Snapper should be the first choice.
Seems some of us will need to read up on BTRFS.
I’ve yet to use it. Although, when I did the last disk swap on this one, I was tempted to change the root partition to BTRFS.
Long story short, because the upcoming Manjaro Summit edition uses atomic btrfs
snapshots as its upgrade process, and this brings the regular editions in line with that, so that people who currently use Stable would be able to switch to Summit later without too much trouble.
Longer version of the story, btrfs
is vastly superior to ext4
. It is self-healing, it has built-in checksums, it is copy-on-write, it has built-in compression, and it journals both the data and the metadata. It is also faster, because it uses balanced trees — hence the name: B-Tree File System.
There is no modification required. timeshift
has always been able to do that. You configure it however you want.
That’s a bad attitude. You’re installing a UNIX operating system, not a household kitchen sink appliance.
And you don’t have to stick to the defaults either. You still have the option to partition your drive however you like, and with whatever filesystems you like.
Yes I just clicked, every other install of Manjaro was just click.
Whatever.
The only issue I see with btrfs is its strange behavior about free space. Free is not free, you have to “Pay special attention to unallocated”.
It might be a good idea to set up a service that checks the unallocated value every reboot and in case it’s less than 15%, asks if you want to do a btrfs balance start -musage=90 -dusage=90
to make room and avoid running out of space.
I converted to zfs a couple of months ago and I love it. It was a bit of a pita since no support in Manjaro installer for booting from it. I wondered about btrfs but decided I needed to dog food zfs so I can better support my server. I honestly don’t know how the two differs
They are very similar and they do pretty much the same things, but they do it differently under the hood.
One difference for instance is that btrfs
subvolumes are not block devices, while zfs
subvolumes are, just as in the event of lvm2
volumes. Another difference is that zfs
has more versatile RAID support while btrfs
only supports RAID 0, RAID 1 and RAID 10 — its RAID 5 and 6 are still very experimental, and their use is explicitly warned against by the developers.
Please only use -dusage
to create free space. -musage
is not recommended by the developers for this purpose.
The out-of-space problem with btrfs is actually a bit more complicated.
The first problem is the user’s stinginess. Instead of expanding the storage space – which is super easy with btrfs – in a timely manner, they simply carry on. In the past, this was prevented by only allowing write access to root at 95% full. But it’s not that simple anymore.
Btrfs needs space to breathe. That means at least a few chunks (1 GB each). 10-20 chunks should be enough to avoid hitting the wall.
But even before that, btrfs becomes increasingly ineffective the more % of the storage space is used up. From 90% onwards, btrfs must frequently relocate data to create space. This happens in the background, but it requires processing power and storage bandwidth. That’s the price for filling up the disk so much.
A common mistake is keeping too many “old” snapshots. This takes up a lot of space, because Manjaro, as a rolling release, changes a lot of data per update and makes a lot of updates. So, if possible, don’t keep it for more than three months.
And if possible, enable compression. This compensates for the space taken up by snapshots
If you really want to be secure, enable RAID in btrfs
You find good Information about Btrfs in the wiki, in Out of space and in About software Raid with btrfs
That is one of my concerns as well, after having read many queries ending up relating to this -
file system (too) full
for example:
I have often used the method of filling up the file system with a file or files … right to the brim - until it errors out because of “no space left on device”
and then deleting these newly created files
to reduce the size of backup images
That would likely not only not work with BTRFS - it would also create a rather major emergency situation.
No?
There are more efficient methods to back up data, I know.
But how about (accidentally) filling up the file system?
… easy to recover?
So you’re using disk images as backups? Fill the filesystem, create image, mount image and delete files?
If so, then wouldn’t using a proper backup utility be quicker and easier?
btrfs is strange (compared to many “old” file systems
)
This means you can’t use “old tricks” (hacks) because they won’t work with btrfs. You must learn and use “new tricks”
What you did as a “hack” is already built into btrfs. Backups made with “send & receive” contain only current data, and no empty space from deleted files.
And if you use “-c” backups receive already compressed data out of the filesystem without expanding and re-compressing it
Yes
→ see how in the wiki
If so, somebody with wiki edit ability should edit “Btrfs Maintenance” page, “Balance your free disk space” section and delete all the -musage indications to avoid its use.