Fedora Cloud 35 Approved To Use Btrfs By Default

[S.Pam]

Benchmarks here on Phoronix........

Seems att least on par with ext4 here :
https://www.phoronix.com/scan.php?pa...esystems&num=4



For one. Disable atime - please. With relatime you get other issues that could be worse than atime if you use snapshots or reflinks.

Two. Use space_cache=v2

Three. Use dup metadata profile for single devices, including ssd.

Anything to backup that statement? For general use most people wouldn't know the difference.

Benchmarks here on Phoronix........

[S.Pam]

Hm, Btrfs features seem great, but performance leaves a lot to be desired. Seems useful for hard drives though.

Anything to backup that statement? For general use most people wouldn't know the difference.

Hm, Btrfs features seem great, but performance leaves a lot to be desired. Seems useful for hard drives though.

[jochendemuth]

Your experience does show that general knowledge of cow filesystems in general , and of course btrfs needs to improve. We need better and clearer documentation and other sources of information that helps in reaching users.

Well, generally agreed.

I asked the question why a different behavior than the established methods is necessary. 99.99% of users don't even know what a file system is or that they need one. btrfs / or cow filesystems in general have some way to go to get there.

That you were experiencing issues with your root sounds to me like hw issues - lost writes for example. This could be write cache reordering, sata channel resets or disk firmware that simply drops or corrupts data.

Btrfs uses 'single' profile metadata on all non-rotational disks by default. This is IMHO a very bad choice for most people as bit flips and other hw issues easily could lead to your situation.

Best to always use 'dup' metadata profile by doing mkfs.brfs -m dup for every single disk filesystem. On multiple disk filesystem, Btrfs uses raid1 as default which is the safe choice.

Yep, almost certainly hw issues. Haven't quite found out - didn't have time to look into it yet. For me Fedora 34 now runs on a different SSD. Maybe I'll find the time to look into the hw issue this weekend and report back...

[jochendemuth]

Btrfs takes the safe decision which is to not do anything, rather than to make a guess and leave the user thinking everything is fine.

I think that is the correct action for btrfs at its current state.

With ext4 and fsck you can easily end up in a situation where it has linked the wrong inode to a filename or deleted a file that is supposed to exist. And if it does that, the user has no idea that happened.

During an ext fsck you have the option to make decisions yourself. So, what do you pick when the message is "inode 3939992 possibly lost. Recover?" or "Block 3993992992 shared by inode 33322 and inode 993993?" Or you can tell fsck to make its best guess. And who knows where the files and blocks will end up.

Agreed - possible (happened to me before), but imho extremely rare. That's why the non-interactive mode of fsck is extremely conservative. I am not sure, it may even only produce decent error messages in the message log. In difficult cases that may be the desirable outcome.

ext4 and other filesystems have just matured a few steps beyond the current state of reliability of btrfs. That's not bad - it's just why I don't consider btrfs ready for root file systems. I think Fedora made the wrong call - or rather made the call too early.

[Zan Lynx]

If there is a tool that can recover everything, why doesn't it just repair the existing file system instead of leaving it unusable? Maybe it could have repaired it with some minor losses (e.g. loss of snapshots), which could have been acceptable (in my case there were no snapshots). I understand that we're talking about a technically quite complicated piece of technology. I just point out that the experience is not acceptable to me - especially since every other file system seems to fail more gracefully.

Btrfs takes the safe decision which is to not do anything, rather than to make a guess and leave the user thinking everything is fine.

With ext4 and fsck you can easily end up in a situation where it has linked the wrong inode to a filename or deleted a file that is supposed to exist. And if it does that, the user has no idea that happened.

During an ext fsck you have the option to make decisions yourself. So, what do you pick when the message is "inode 3939992 possibly lost. Recover?" or "Block 3993992992 shared by inode 33322 and inode 993993?" Or you can tell fsck to make its best guess. And who knows where the files and blocks will end up.

[mykolak]

You probably have not noticed the standard recovery tools at work because in most distributions they run automatically at system mount time in case of issues. While the file system specific fsck tools don't solve "every" problem they have proven effective in the vast majority of issues for decades.

So, yeah, surely I've seen ext4 fsck at startups (though in last years haven't noticed them). But fsck isn't a recovery tool — it is check and repair. And birdie was talking about recovery if I haven't missed something.

If you are missing exactly fsck for btrfs, there are some notes:
1. In most cases when ext4 need fsck btrfs doesn't.
2. There are different btrfs tools: check, scrub, rescue, restore — for different tasks.

[mykolak]

It's an alternative phrasing of "You probably have not noticed when the standard recovery tools were running". (eg. Restoring journals and running fsck just happens as part of the boot process and, if you turned your computer on and then went you make breakfast, you might not have noticed that it took longer than usual.)

Oh, thanks, I was thinking of exactly that case and was reading it as "You ... at work", not "... tools at work", my bad.

[S.Pam]

I appreciate your sentiment. Fortunately, I did not lose data. I am aware that Fedora is pushing the envelope and therefore keep critical data separate (and backed up) from the root file system. However, I lost a complete OS install including a list of customizations that I use for creature comfort. That's a couple of hours of work that I wish I didn't have to invest (a root file system failure forces you to act - other issues can often be ignored for a while). So, not a big issue for me in the large scheme of things. However, a potentially a much bigger issue for someone else.

You can tell that these are my first posts in this forum. I considered my experience (and yes, frustration) valuable enough to spend time to share it.

When I created a fresh install of Fedora 33 I gave btrfs a try since Fedora recommended it even for the root partition. At that time I was excited about it because I have been using zfs for a few years now with a generally very positive experience, although not without its challenges.

I should explain that I am currently maintaining several zfs pools, but not for root partitions. I benefit a lot from features like inline compression and snapshot based backups. The biggest challenge with zfs is the dkms based kernel module in Fedora. Upgrading to new kernel versions has improved a lot recently, but still breaks occasionally. That keeps me from using zfs for root partitions for now.

So, btrfs seems to offer quite similar concepts, but integrated in the kernel. That's a big benefit. Also, more choices are always good.

This setup (largely a default Fedora 33 Workstation) worked fine with any noticeable change nor benefit for a few months. Then, I suddenly started getting weird error messages that were caused by the root filesystem suddenly having become read-only.
Rebooting seemed to solve the issue at first - but eventually, the root file system got switched to read-only within seconds of a boot. Dmesg/journalctl indicated a file system error as a cause for this, so off to a file system check.
"man btrfs" quickly explained that there is no fsck command. Since, we're talking about potential modification (a fix) to the root file system I decided to find an alternate partition/medium to boot before running a "btrfs check --repair". After that command completed, I couldn't mount the partition - not even read-only. Great tool!
Yes, "btrfs restore" allowed me to recover everything. Again - from an end user point of view I have to wonder: If there is a tool that can recover everything, why doesn't it just repair the existing file system instead of leaving it unusable? Maybe it could have repaired it with some minor losses (e.g. loss of snapshots), which could have been acceptable (in my case there were no snapshots). I understand that we're talking about a technically quite complicated piece of technology. I just point out that the experience is not acceptable to me - especially since every other file system seems to fail more gracefully. Again - in my experience. Because I had file system issues with every file system I tried over the years, I feel my experience is worth sharing.

I think that my experience is probably rare and I fully expect "btrfs check --repair" to be working like a charm in the majority of cases.

However, if someone reads my post(s) and decides to implement time in a proper backup that saves him time and a loss, then it was worth it IMHO

Did you read the man page? First thing it has is:

Warning: Do not use --repair unless you are advised to do so by a developer or an experienced user

Your experience does show that general knowledge of cow filesystems in general , and of course btrfs needs to improve. We need better and clearer documentation and other sources of information that helps in reaching users.

That you were experiencing issues with your root sounds to me like hw issues - lost writes for example. This could be wite cache reordering, sata channel resets or disk firmware that simply drops or corrupts data.

Btrfs uses 'single' profile metadata on all non-rotational disks by default. This is IMHO a very bad choice for most people as bit flips and other hw issues easily could lead to your situation.

Best to always use 'dup' metadata profile by doing mkfs.brfs -m dup for every single disk filesystem. On multiple disk filesystem, Btrfs uses raid1 as default which is the safe choice.