>(if Alexandre is willing to do some further
>testing to put numbers on the problem)?

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
> read, it *seems* like that WD Blue SSD is wonkier than it should be.

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.

On Sun, Jun 28, 2020 at 11:21 AM Michael Catanzaro <mcatanz...@gnome.org>
wrote:

> On Sun, Jun 28, 2020 at 4:11 pm, Fabio Valentini <decatho...@gmail.com>
> wrote:
> > Maybe libvirt / gnome-boxes / virt-manager should do that by default
> > if it detects that the backing storage for an allocated VM image is
> > on btrfs (if it doesn't do that already)?
>
> Yeah that's the plan:
> https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/88
>
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to