On Sun, Jun 28, 2020, 16:04 Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Sun, Jun 28, 2020 at 9:57 AM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote:
>
> (fixing the subject line to not mention nano)
>
> On Sun, Jun 28, 2020 at 5:16 am, alexandrebfarias@xxxxxxxxx wrote:
> > Don't expect much love on this, since my opinion has been downvoted
> > on reddit by many of those who don't want to hear bad news about
> > btrfs. And no, I don't have any benchmarks and did not collect any
> > logs, I'm not talking about a bug, BTRFS is defective beyond anything
> > Fedora could do to fix it. After spending so much time fighting
> > against my system
>
> Well the btrfs change proposal exists to improve the user experience.
> User experience is the overriding goal behind everything we do. I've
> just finished wading through the rest of the btrfs discussion, finding
> most concerns about the filesystem not very compelling... but your
> experience with btrfs is concerning to me. It seems you suffered from a
> serious I/O performance issue. Since one of the goals of this proposal
> is to *improve* system responsiveness under heavy load, it should go
> without saying that we don't want to introduce noticeable performance
> issues. I wonder if the change owners have any idea what might have
> gone wrong for Alexandre? Is this something we could attempt to
> reproduce and measure (if Alexandre is willing to do some further
> testing to put numbers on the problem)?
>
> Alexandre, if you could provide an estimate of approximately when this
> happened (approximate kernel version)...?
>
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.
When I first looked at SSDs three years ago, I'd see weird performance
behavior like that depending on brand and model. I can't prove
anything in this case because I don't know anything about that SSD,
nor do I have any logs or ability to diagnose it (or even that
particular SSD device on hand), but I'd be concerned about the drive
maybe having a fault. One of the reasons I recommend Samsung EVO SSDs
is because they have been consistently reliable for me across several
generations.
But, I just don't know enough to provide a good answer here.
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.
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)?
Fabio
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
