I'm willing to perform further testing. There shouldn't be anything very special about my workload. I was working mostly with NodeJS 12 and React Native. VS Code (I should mention I make use of TabNine, which can be a huge drain on system resources). So, in a typical work session I'd have android emulator open, PostgreSQL, some chrome tabs, VS Code, probably Emacs, plus the React Native metro server and an Express.js backend. Everything felt slower than it did on Windows, while now it feels much faster. The only system that comes to my mind when comparing performance now and performance with BTRFS is the Pentium III 1000MHz I had many years ago (even with nodatacow followed by rebalancing and defragmenting).

>Alexandre, if you could provide an estimate of approximately when this
>happened (approximate kernel version)...?

I've actually tried many kernel versions over the last few months and do not believe the kernel version had any impact/

I still have some of the logs since my current system was cloned from the BTRFS one. The first version I tested was 5.6.0-0.rc5.git0.2.fc32.x86_64 (I downloaded the RC image a few days before the official release).

After release I kept running into space constraints, which I thought were contributing to the extremely degraded performance. In my attempts to fix that, I tried rebalancing and defragmenting multiple times. I did increase the partition size in order to try and fix the problem, without success, in order to try and make sure the on disk layout was the best it could be). Also tried tweaking the mount flags (i.e. by adding noatime) but the difference was negligible.

My last efforts to salvage my BTRFS experience (and I really wanted to love this filesystem) were with 5.6.19 and even 5.7.4 (I started with the testing repos enabled, and then disabled  them and went to a stable kernel when things started going south).

I'm aware there could be a number of factors resulting in my poor experience, but then everything started working just by rsyncing over to a XFS filesystem. I pretty much tried everything else before doing this, from changing kernel versions to trying every possible combination of graphics driver.

part /boot/efi --fstype="efi" --noformat --fsoptions="umask=0077,shortname=winnt"
part swap --fstype="swap" --ondisk=sda --size=8008
part btrfs.475 --fstype="btrfs" --ondisk=sda --size=93368
part /boot --fstype="ext4" --ondisk=sda --size=1024
btrfs none --label=fedora_localhost-live btrfs.475
btrfs / --subvol --name=root LABEL=fedora_localhost-live
btrfs /home --subvol --name=home LABEL=fedora_localhost-live

> I would definitely be interested in more data here, but from what I

Any specific testing procedures to try and test this hypothesis?

> From what I remember about Android Studio / Simulator, it uses qemu and disk images under the hood. Setting the nodatacow attribute (chattr +C, I think?) on VM images should improve performance by a fair bit.

I did eventually follow this recommendation as per multiple sources. But even then, performance was sub-par (it was useable but it kept getting slower with time).

I did perform the following commands on every folder which had containers or VMs:

$ mv /path/to/dir /path/to/dir_old
$ mkdir /path/to/dir
$ chattr +C /path/to/dir
$ cp -a /path/to/dir_old/* /path/to/dir
$ rm -rf /path/to/dir_old

> Maybe libvirt / gnome-boxes / virt-manager should do that by default

It surely is necessary. I don't think it was doing that by default (at least with virt-manager, don't know about Gnome Boxes). But then, again, there are packages like Android Emulator which are commonly used for development and I'm not sure whether anything could be done besides warning the user.