> This has happened to me because OpenSUSE and Jolla's Sailfish OS use btrfs as 
> their
> default file system. I've tried using btrfs from time to time in various 
> environments
> to see how it's progressing. However there hasn't been fixes for long-standing
> issues in btrfs when it comes to desktops and laptops in years. Btrfs can 
> still for
> example run out of its automatically manager "metadata space" which it cannot
> recover from. Even the relatively recent improvement in kernel 5.8 have 
> already been
> proven to not improve the situation much although at least the subvolume 
> deletion failing
> over lack of disk space is now handled slightly better.

It's `openSUSE` not `OpenSUSE`. The metadata issue was mentioned in this
thread before multiple times too. It's rare, but it happens

> I'm honestly in shock that this is even a discussion right now again. If 
> there is a
> legitimate urgent need to switch the default file system for desktop and 
> laptop users (and
> I understand why there is pressure to do so since ext4 has a number of 
> shortcomings), then
> whatever legal obstacles there are blocking the use of zfs should be cleared 
> and zfs
> should be used instead. Canonical with their Ubuntu is already trying to do 
> this through
> use of OpenZFS. The xfs has started to have issues as of late but even it 
> would be a
> legitimate choice.

I know of one brave soul that maintained zfs based Tumbleweed install,
and planned to have that included in the repos, but that died after nth
kernel update breaking it. I think rolling/semi-rolling distros cannot
ship OpenZFS, without it being release-blocking for kernel updates,
because people kinda rely on their filesystem working. We already kinda
had that dilemma with Nvidia driver on openSUSE side, and decided that
kernel might actually be more important than any third party software
that doesn't work with the new kernel, so OpenZFS is entirely out of the

> The absolute first issue with btrfs in desktops and laptops is that it 
> requires active
> conscious maintenance from the end-users to avoid large number of potentially 
> disastrous
> situations as well as unconscious regular automatic constant maintenance on 
> background
> which consume the disks and eat resources. Based on my experiences btrfs 
> works best when
> you don't use the features you supposedly install it for. It's snapshots are a
> great example of that. Which is why I suspect that most btrfs "success 
> stories"
> are ones where the users don't take advantage of the btrfs' features or have
> actively turned them off conscious of issues they bring up later on. Using 
> btrfs
> doesn't make using PC easier and instead does the opposite by adding more 
> work.
> Meanwhile zfs has reliable and working snapshots feature which is in actual 
> use.

Those are edge cases, on a single disk setup, you shouldn't need to run
maintenance scripts nor have them run automatically. We have those
running on openSUSE distros because as I mentioned, SUSE doesn't care
about desktop, so those are inherited from how servers do it

> And what inevitably happens with btrfs root volume is that the system can and 
> will stop
> booting after period of "strange behaviour". Sometimes it can be resolved in
> maintenance mode but usually the end-user then has to boot a live 
> environment, chroot
> their system, and clear all hopefully backup'd large files if the system is 
> not in
> read-only (or clear that obstacle first), clear (most) snapshots, run 
> btrfs-balance
> operation and do it very carefully or the entire file system might be lost. 
> This will take
> a very long-time (ranging from 30 minutes to some hours and up to 3-4 days 
> based on my
> experiences) even on a relatively small SSDs (not to mention HDDs) and it 
> also will
> shorten SSD lifespan.

Generally you could use the following guide
since it's faster than guessing what to do. I assume btrfs-balance is
guessing what to do, because it doesn't make sense in the scenario

> The btrfs-check is also a massive can of worms and it cannot be safely run. 
> At least not
> without reading pages upon pages of manual and becoming an expert in 
> understanding how
> btrfs works. Expecting every Fedora end-user to do this is unrealistic in 
> many different
> ways.

Linking again to a very short and very linear and very easy to follow
set of step to recover btrfs volume, where the last step is
`btrfs check --repair`, if everything else fails ;)
It's certainly not pages upon pages of manual, it's a short subsection
of a longer Support DB article.

> The btrfs has no native encryption to my knowledge. However alternatives such 
> as zfs
> already has a trusted and reliable encryption used in numerous FreeNAS 
> installations
> around the world.

Until then, you can use luks since that's how every other filesystem
in Linux has done it. For that matter, FreeNAS's zfs uses geli (luks but
bsd not linux) and not zfs' native encryption

> And much of these issues and many more are straight up mentioned in btrfs' 
> own wiki
> pages at kernel.org where one of the most shocking admissions is: "So, in 
> general, it
> is impossible to give an accurate estimate of the amount of free space on any 
> btrfs
> filesystem. Yes, this sucks."
> Source:
> https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complica...
> And these are the brains before btrfs admitting this that there is no 
> solution for this.
> No amount of userspace tools developmen and UX/DE integration is going to 
> solve this for
> the end-users.

The default partitioning will not be raid. This will be an issue with
any filesystem with features like btrfs on raid.

LCP [Stasiek]
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to