Re: List of long term FTBFS packages to be retired in August
I'm interested in helping with those NodeJS packages. -- Alexandre de Farias / etinin On Mon, Jun 29, 2020, 12:50 Vít Ondruch wrote: > > Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a): > > js-jquery1 nodejs-sig, patches, vondruch Fedora 30 > > js-jquery2 vondruchFedora 30 > > js-sizzle nodejs-sig, patches, vondruch Fedora 30 > > > > I was ranting about js-jquery (and js-sizzle is dependency of js-jquery) > on this list already several times. I picked it up just to keep it alive > in whatever state, because bundling it everywhere won't make things > better. So is there anybody who would like to give it some love? Or > should I let the packages finally go and let everybody else to bundle > whatever they want? > > > > Vít > > ___ > 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
Re: User experience issue on btrfs
>(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 wrote: > On Sun, Jun 28, 2020 at 4:11 pm, Fabio Valentini > 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
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Hello, I decided to register just so I could offer my humble take on this. First of all, I have many years of Linux experience (mostly on Debian and Gentoo), but after years without having Linux on my desktop environments (though I did use it on all servers I have managed, mostly on the Debian side of things). Seeing the currently offered options, even though I almost nil experience with RHEL/CentOS/Fedora systems, I decided to go with Fedora earlier this year (just before F32 was released). BTRFS drove me an inch away from completely removing Fedora from my system and never looking back again. I mean, it couldn't be just a file system, it seemed impossible that deeper issues within the distro weren't involved. Android emulator went literally unusable. Images that podman would build 10x times faster in lower specced servers. Turned off datacow on the folders containing the vm images/container fs's and copied them in order to get rid of the fragmentation. Things were a little better, but performance was still degrading every single day. I just threw the towel and turned off datacow entirely as a palliative, which made the system somewhat usable but also made btrfs a toothless tiger, took away all of its compelling features. All of this was on a Predator Helios 300 - 572 notebook, i7 7700, 32gb ram, dedicated Nvidia 1060, with the BTRFS system installed on a 500GB WD Blue SSD. At this point I was starting to wonder whether Fedora, Gnome or even Linux were a viable choice of this machine, it seemed my computer wasn't getting along with the system at all. Only reason I still have Fedora is that I managed to backup the data on my NVME WD Black 256GB drive, wiped it and created a new XFS partition as a last ditch effort (also mirroring the previous Swap / boot layout, but this time I had swap encryption) I mean, of course the PCI-E interface is fast than the SATA one, but the difference is barely noticeable during daily usage. And while I had BTRFS as a raw partition, XFS was on top of LVM and LUKS. My WD Blue SSD is also, fine tested it over and over again to make sure and my previous Windows installation ran there and performed just fine. Wasn't very hopeful, but after a simple rsync and simply pointing grub to the new XFS partition gave a whole new life to my system. The sizes were very similar (the BTRFS partition had about 230GB), so it can't come down to that. The difference was so absurd I couldn't believe I was actually enjoying the exact same system just because of a FS change. I really wish I could provide benchmarks to back my claim but at this point I was quite fed up and had lost a lot of productive time because of the countless hang-ups and even crashes I experienced with btrfs. 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 So, deciding to come back to Linux after getting fed up with Windows, meant that I'd have to make some choices. Foremost of all for me, after choosing Fedora, was choosing a suitable filesystem. I installed it on a partition taking about half of a pretty decent WD Blue SSD. I actually expected btrfs to be one of the best aspects of my experience, was quite excited to make use of its capabilities (and I didn't even get to using RAID features, which are knowingly riddled with defects). I've never thought much of ext4 and in the past I just went with JFS for my desktop machines. I mean, my machine is pretty decent, the performance impact couldn't be that bad, even seeing the benchmarks. Turns out I was wrong. My system was pretty much unusable after some weeks. Even defragmenting and doing every kind of mount flag option optimization known to man didn't make the situation any better. Turning off CoW was the only thing that made me able to even perform simple tasks on my otherwise performant computer. With all due respect, this proposal is borderline wreckless. There is not a single benchmark out there showing BTRFS is suitable for any common workload of an average Fedora user. Anedoctal experience is even worse. I'm boarding an airplane right now and this e-mail should be quite disorganized, but I had to leave my 2cents I'm not surprised RHEL completely got rid of BTRFS and not even oracle is using it as a default for their Enterprise Linux. ___ 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
