Fedora Cloud 35 Approved To Use Btrfs By Default

[intelfx]

There's a reason not to ever use btrfs: there are basically no tools to recover data from it in case it becomes broken (aside from grep'ping which won't allow you to restore anything but basic text files)

man btrfs restore and stop spreading FUD.

[intelfx]

Well, when my Fedora 33 install using BTRFS got corrupted I had to learn that there is no fsck util for it and that my install was lost. The lack of ability to repair is a big no-no for root file systems.
A complete root file system loss hasn't happened to me with any other file system in the last 30 years (ext[234], xfs, zfs - hell, even MSFT ones). This file system is just dangerous.

I understand and generally appreciate the dogmatic focus on "compatible licenses" for including software packages into its distribution, but Fedora needs to make it easier to bring in certain 3rd party software. For graphic card drivers Fedora finally - after many years of suffering - caved and improved the install process for NVidia drivers - the nouveau driver will never support current hardware. Same needs to happen for modern file systems: zfs is proven, stable, and well maintained. How long will it take for Fedora to realize that BTRFS will not catch up? Instead of wasting developer resources on a losing battle, commit them to simplify zfs driver install, support of zfs as root file system, improve OS config to backup and manage package upgrades using zfs snapshots.

So, you dislike btrfs intensely because it has no useful fsck, and at the same time advocate for zfs, which... also has no fsck, not at all, not even a btrfs restore-type tool?

[S.Pam]

Well, when my Fedora 33 install using BTRFS got corrupted I had to learn that there is no fsck util for it and that my install was lost. The lack of ability to repair is a big no-no for root file systems.
A complete root file system loss hasn't happened to me with any other file system in the last 30 years (ext[234], xfs, zfs - hell, even MSFT ones). This file system is just dangerous.

I understand and generally appreciate the dogmatic focus on "compatible licenses" for including software packages into its distribution, but Fedora needs to make it easier to bring in certain 3rd party software. For graphic card drivers Fedora finally - after many years of suffering - caved and improved the install process for NVidia drivers - the nouveau driver will never support current hardware. Same needs to happen for modern file systems: zfs is proven, stable, and well maintained. How long will it take for Fedora to realize that BTRFS will not catch up? Instead of wasting developer resources on a losing battle, commit them to simplify zfs driver install, support of zfs as root file system, improve OS config to backup and manage package upgrades using zfs snapshots.

I'm sorry you lost your data. The concept of fsck is different for CoW filesystems like Btrfs, ZFS and ReFS. You made assumptions and perhaps because of it missed an opportunity to save your data.

There certainly are tools that can help recover from a broken btrfs filesystem.

[jochendemuth]

I'm sorry you lost your data. The concept of fsck is different for CoW filesystems like Btrfs, ZFS and ReFS. You made assumptions and perhaps because of it missed an opportunity to save your data.

There certainly are tools that can help recover from a broken btrfs filesystem.

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

[jochendemuth]

This is incorrect. Btrfs certainly has a fsck utility. It is just called by a different name now.

https://btrfs.wiki.kernel.org/index.php/Btrfsck

The above mentioned link explained that "btrfs check --repair (used to be called btrfsck)". This means that there was a conscious decision to not support the established fsck utility/facility.

I don't know nor did I research reasons for this - however, the fsck facility has served me well for quite a long time (decades). From the point of me as a user I see that there is a utility called fsck supporting a set of command line options that tries to identify the partition type and upon positive identification calls a file system specific utility based on a naming convention. Simple enough, proven to be useful.

So, any conscious decision against supporting it is at least worth asking about. In case anyone knows more or can point me in the right direction, that would be appreciated.

[jochendemuth]

So, you dislike btrfs intensely because it has no useful fsck, and at the same time advocate for zfs, which... also has no fsck, not at all, not even a btrfs restore-type tool?

Well, yes, I can see how that seems confusing. I should explain that better.

When there is a single solution to a problem, that's by default the best solution there is. As soon as there is a second solution it begs the question which is the "better" solution. We all are aware of this and understand that "better" often is very nuanced and a personal choice.

Specific to file systems there is a myriad of choices. I personally have actively participated in the transition to journaling file systems, tried many file systems, file systems on raid, file systems on volume managers, even ran file system benchmarks between ext2/ext3/ext4/xfs/reiserfs and tried to "tune" file systems. The increase in reliability through journaling was astounding, the time saved when recovering from issues was breath taking. Simply said - around that time I mostly stopped worrying about reliability of file systems. Also, a fun learning experience.
Then, for quite a while I thought file systems were researched to death and decided to stick with the default (ext4 for Linux) prioritizing the ease-of-use that comes with a default over other potential benefits. I should say that all this predates SSDs :chuckle:

Obviously, since then new use cases have emerged and new solutions to the challenge of file systems. A few years ago I decided to give zfs a try and was blown away by all the opportunities it offers. Some immediate benefits, some medium to long term opportunities. It took me a while to learn the new concepts and how to deal with challenging situations. I certainly had to learn some difficult lessons leading to the recreation of pools. I had to learn more than I care for about the process and challenges deploying kernel modules.

However, I find that zfs clearly offers strong set of features and benefits on top of the existing class of journaling file systems. For reasons I explained in another post I don't quite trust it as a root file system, but I like it enough to hope for a zfs (or similar) root file system solution that replaces ext4.

One feature that I consider a must-have for any file system is reliability. You trust a file system with your data. Facilities to deal with issues are a feature that I took for granted (until you pointed out that zfs apparently doesn't offer a fsck - instead it offers a proactive scrub feature). My experience with btrfs was shocking given that it was elevated to root file system status by Fedora. I generally trust Fedora - using it since Fedora Core 8 and only have experienced minor issues that generally get fixed in a short time. I did not expect a complete system failure.

So - in my experience comparing btrfs against other file systems, it fails in a criteria I consider a must-have, in a way it reverts back to a situation that was solved decades ago. That eliminates it for me from contension for a while. (please note the strong emphasis on my personal experience).

To get back to my orginal point: My post was meant to advocate for graceful failure. That's something I have experienced with the fsck facility. As a facility that used to be built deep into the OS (I haven't checked if it's still used with systemd) it worked.

I advocate for zfs as an example of technology that is quite similar in nature and scope to btrfs but seemingly without the current downsides. Up to this point I did not have a file system corruption with zfs and therefore no need for a fsck utility. I generally find that zfs fails fairly gracefully.

[intelfx]

One feature that I consider a must-have for any file system is reliability. You trust a file system with your data. Facilities to deal with issues are a feature that I took for granted (until you pointed out that zfs apparently doesn't offer a fsck - instead it offers a proactive scrub feature). My experience with btrfs was shocking given that it was elevated to root file system status by Fedora. I generally trust Fedora - using it since Fedora Core 8 and only have experienced minor issues that generally get fixed in a short time. I did not expect a complete system failure.

A fsck tool and a scrub feature are completely different things. Btrfs also has a scrub feature that is fully equivalent to zfs', while the latter has no fsck tool whatsoever.

If a zfs filesystem gets damaged enough that it becomes un-mountable, zfs driver will bluntly tell you, and I quote, to destroy the pool and restore from backup. There are no recovery facilities.

So - in my experience comparing btrfs against other file systems, it fails in a criteria I consider a must-have, in a way it reverts back to a situation that was solved decades ago. That eliminates it for me from contension for a while. (please note the strong emphasis on my personal experience).

To get back to my orginal point: My post was meant to advocate for graceful failure. That's something I have experienced with the fsck facility. As a facility that used to be built deep into the OS (I haven't checked if it's still used with systemd) it worked.

I advocate for zfs as an example of technology that is quite similar in nature and scope to btrfs but seemingly without the current downsides. Up to this point I did not have a file system corruption with zfs and therefore no need for a fsck utility. I generally find that zfs fails fairly gracefully.

Even with all the emphasis on personal experience and what-not, you still condemn btrfs for something that you at the same time praise zfs for.

[RahulSundaram]

The above mentioned link explained that "btrfs check --repair (used to be called btrfsck)". This means that there was a conscious decision to not support the established fsck utility/facility.

I don't know nor did I research reasons for this - however, the fsck facility has served me well for quite a long time (decades). From the point of me as a user I see that there is a utility called fsck supporting a set of command line options that tries to identify the partition type and upon positive identification calls a file system specific utility based on a naming convention. Simple enough, proven to be useful.

So, any conscious decision against supporting it is at least worth asking about. In case anyone knows more or can point me in the right direction, that would be appreciated.

The tldr is that COW filesystems like Btrfs are considerably different with advanced features. Routinely running fsck against it is unnecessary and prioritizing restoring the filesystem itself over protecting the data isn't the right tradeoff in most cases. This is why tools like btrfs restore exist https://btrfs.wiki.kernel.org/index.php/Restore and you should use them instead of reaching out to fsck as the first step like you have been doing for other filesystems. It is for similar reasons you are asked to use btrfs filesystem du instead of du since du doesn't know about shared storage and snapshots etc.

[CochainComplex]

Doesn't support shrink, You can grow it.

Oh you are right. The last couple of operations I tried on xfs was always shrinking. I forgot the other way around works

[mykolak]

You probably have not noticed the standard recovery tools at work

/*
I didn't get that part. Why at work, why you assumed I haven't noticed?
*/
EDIT: ssokolow explained it already

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.

Start of volume was corrupted it wasn't even detected as ext4 anymore, so fsck definitely not right tool and volume it was not possible to mount it as well. But while rest of the volume was intact I haven't found a tool to resurrect most of the files, mostly there was garbage "files".