Fedora 33 To Be Released Next Week

[flower]

One feature that you might have missed is resource management, in particular responsiveness. Gnome and KDE both push in the direction of using systemd with cgroups much more, which allows to prioritize e.g. system processes over normal or background ones (1). BTRFS apparently plays much better with that.
So getting a bigger share of the user base to BTRFS lays the groundwork for a better user experience when under heavy IO, even if it's slower for certain tasks.

1: GUADEC video: https://www.youtube.com/watch?v=cmYCM3S_YEY

Good one! Thank you. Will watch it later

[Alexmitter]

Cant wait. Will pair the switch to btrfs with a nice new NVME disk.

[S.Pam]

Ssd and nvme has a tendency to do bit flips and such. Btrfs csum is invaluable in those cases! Doesn't matter if it is on laptops or nas boxes or desktops. I had a corrupt block on my Samsung SSD the other day. Btrfs saved my ass there because it happened on my boot/vmlinuz

Didn't Michael post some benchmarks recently that shows btrfs is not slower than ext4 is majority of tasks? Not that it really matters that much these days.

Regarding sqlite. Enable WAL and it is nice on cow filesystems! https://sqlite.org/wal.html

Someone mentioned LVM for csum/integrity. That is _abysmally_ slow! Also still buggy.

[intelfx]

I still see no reason to use btrfs and will stick to ext4

Performance? Well ext4 is better in nearly task
Fragmentation? Ext4 wins by a big and performance noticeable margin (eg firefox sqlite db)
Snapshots? Lvm
Dedup? Lvm
Raid? Lvm
Bitrot detection? Lvm (no corrections though, but well i have backups)
Compression? Btrfs is a winner. But i have enough space and my biggest files are not compressable anyway

Did i miss something? Or is btrfs just a solution without a problem

LVM only "solves" anything you mentioned if your goal is to tick a checkbox. In practice, LVM solutions to these problems are abysmally bad.

LVM snapshots are fail-deadly and require manual space management.
LVM raid is even worse than mdraid. It has lots of missing features, and, like mdraid, only protects from full disk outages, not bitrot.
LVM deduplication is experimental and... well, that's it, also snapshots caveats apply.
LVM bitrot detection — ??? Does it even exist?

By the way, even if you pair mdraid/lvmraid with dm-integrity to handle bitrot, its answer to any form of corruption is "let's throw away the whole disk and rebuild the array from scratch", which is not just counterproductive, but also dangerous. Considering modern disk sizes, it is statistically non-negligible that you will experience another read error while rebuilding, throwing the whole array into the trash bin.

So yeah, you absolutely did miss something. LVM is a technology with lots of deficiencies that covers only half of usecases.

Therefore, rather than the populist lie of "LVM does everything you ever need, btrfs is a solution without a problem", the actual problem is pragmatic — there are two technologies, each with its benefits and deficiencies. Given two competing technologies where each requires work, it makes sense to focus on stabilizing the modern technology rather than endlessly beating the dead horse.

[skeevy420]

It's a filesystem not sex with your girlfriend/boyfriend.. all this obsession for performance it's non-sense, unless we're talking about an abysmal difference!
Whatever turns your libido man

Or why I use ZFS these days. Y'all feel free to replace that with your file system of choice because I'm not trying to start a file system argument.

I'd rather have tons of features because I don't notice the, pulling numbers, 5-10% difference in speed since spinners are slow already and SSDs are usually fast regardless. My spinning mirror feels fast enough for games and my SSD is plenty fast for a desktop. Worst case scenario, I'll have to add backing SSD cache to the mirror because some game doesn't load fast enough. I like knowing advanced features like that are an option more than I want a slightly faster file system.

Plus once encryption and/or compression are factors they usually have more to say in the r/rw speed than the actual file system being used...every file system will slow down if either of those are set high enough. So, again, I figure if I'm trying to save stuff securely or compactly, might as well pick a safer file system over a faster file system. With the goals at hand the speed differences are more than likely negligible.

[ix900]

Or why I use ZFS these days. Y'all feel free to replace that with your file system of choice because I'm not trying to start a file system argument.

Its all silly. But, if an application has a problem with some incompatible file system that's about the only time it actually matters.

[Girolamo_Cavazzoni]

Regarding sqlite. Enable WAL and it is nice on cow filesystems! https://sqlite.org/wal.html

Thanks for that input - how would you activate that in Firefox?

[mattdm]

I know this is tilting against a windmill, but: this is an exactly on time release, and the "Target #1" date is the one you should plan on. We would prefer to have it ready a week early (which is why that's called a preferred date!), but not being early is not a failure.

[C8292]

Running it since beta with default BTRFS.

Awesome Fedora is awesome

[MadeUpName]

Fedora is getting their releases out so frequently and on time now that it stopped being exciting to upgrade. I say that in the most positive way.

Thats because they aren't out o the bleeding edge like they used to be. This release doesn't do much for me. But it clears the way for them to start pulling in new stuff that has been out for quite a while that could make some big differences if they aren't to conservative again.