Re: BTRFS testing Rawhide 0703 WS
On Tue, 2020-07-07 at 14:38 -0400, pmkel...@frontier.com wrote: > > Also, I don't understand why this is raid6 There is only one disk in > my > test machine. Also I did nothing in the btrfs settings to call for a > raid. I just took the btrfs defaults. > That's a misleading log message; see e.g. this discussion https://bbs.archlinux.org/viewtopic.php?id=231884 You probably want to use this to check the actual RAID level. btrfs filesystem df / source: https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_determine_the_raid_level_currently_in_use.3F Best regards, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: Results from install of old drop of WS
On Mon, Jul 20, 2020 at 2:17 PM pmkel...@frontier.com wrote: > Anyway from the discussion, I am under the impression that btrfs uses > compression by default for user's data files. If I am right will there > be a way to turn that off? Upstream doesn't enable it by default. There are a few ideas what it might look like to do by default in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=1851276 Transparent compression has been in Btrfs since early days. Zlib was supported when it was first merged into the kernel around 12 years ago. LZO followed soon after. Zstd is new, but it's supported since kernel 4.14, which isn't definitely not new in Fedora terms. But yeah, you'll be able to turn it off. Whether by mount option or by attribute. It may also be reasonable to opt in or out by kickstart. One option not discussed so far is: do the work to enable it in the installer, and only enable it by default via a GNOME Boxes express installation (injecting a kickstart into the installation). I'm not sure if that's more trouble than it's worth, but it could make for significantly smaller Fedora VMs that are also decently likely to be a bit faster due to (a) typically slower write performance inside of VMs anyway (b) fewer reads and writes results in a net gain in performance due to the compression. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: agenda for todays QA meeting
On Mon, Jul 20, 2020 at 8:23 AM pmkel...@frontier.com wrote: > > Let's talk about zram. > > I just got around to figuring out what zram is. I see it's automatically > set up when Anaconda sets up btrfs. It's setup by zram-generator and zram-generator-defaults being present, and they're installed by default (or should be) on every installation image: netintstall, DVD, Live. And whether you do an automatic or custom installation, regardless of file system. If you do a custom installation and create a disk based swap partition, you will have two swaps and the zram-based one will be used with a higher priority. > First a bit of background all the PCs (Fedora WS) I maintain are bought > with lots of ram 8GB is the min. I don't think I've ever seen swap move > off zero and no one has reported any sort of slowdowns. Yet we do lots > of memory intensive things. Of course all this is with ext4. Are you changing /proc/sys/vm/swappiness to reduce or avoid swapping? The typical case, some swap is used. These are evicted anonymous pages, and it's more efficient for the kernel to do that for stale anonymous pages, rather than reclaim (ejecting file pages from memory. How effective this is does really depend on the workload, but happily that's the vast majority of the time. And I'm still looking for workloads that do poorly (I'm sure we'll find some eventually). > Now I see on my test machine (btrfs) that about 24% (2GB) of the 8GB of > memory (according to monitor) (4GB according to disks) is dedicated to > zram0. I imagine the difference in size reported to due to the > compression used by zram. Yes but also it's a bit misleading because it's dynamically allocated. To see how much memory is actually used you need to look at zramctl output. I'm not actually seeing anywhere in System Monitor where it suggests how much RAM is being used by the zram device. > First I can't think of any good reason why I should need or want to have > any of my ram dedicated to swapping or other things that speed up btrfs. It's not Btrfs specific or related. > Second, a few years back, I looked over some of the compression > algorithms. The probability of loss or corruption was low, but non-zero. True but if you have corruption resulting from memory problems, that's bad no matter how much gets corrupted. The memory must be replaced or you have to figure out the exact location of bad RAM and setup a kernel exclusion memory map as a boot parameter. > I'm sure they have improved, but I'll bet those probabilities are still > non-zero. I was taught back in my early years at school that unnecessary > risk is foolish risk. So I've always avoided using compression where > ever I had an option. The compression itself isn't going to cause corruption. What happens is more data is effectively corrupted, if there's corruption, due to the compression. But you don't want corruption happening in the first place, no matter whether there's compression. > If this is necessary to make btrfs work or get reasonable performance > from it. That is a strike against btrfs. If a workload is going to be slower on btrfs, it'll still be slower whether swaponzram is enabled or not. But if you don't want to use swaponzram, merely 'touch /etc/systemd/zram-generator.conf' and that will permanently disable it. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
IoT release criteria status
Hi QA friends, I'm working with the IoT team to button up the (in-the-process-of-being-approved) process for promotion to Edition. Apart from the fact that the PRD currently lacks the following things: - Core services & features - Core applications - Unique policies for installation, updates, etc how satisfied are you with the state of the release criteria for IoT as an edition (and the subsequent ability to test)? Are there glaring issues we absolutely have to fix or can we improve things iteratively over the next few releases? (I wanted to bring this up in today's meeting, but then I wasn't able to attend most of it. We can discuss next week if there's a meeting) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: Results from install of old drop of WS
On Mon, Jul 20, 2020 at 04:16:52PM -0400, pmkel...@frontier.com wrote: > Anyway from the discussion, I am under the impression that btrfs > uses compression by default for user's data files. If I am right > will there be a way to turn that off? It's still being discussed. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Results from install of old drop of WS
As promised in the QA meeting today I have installed an old drop of WS to find the place in Anaconda I thought was there to turn off or not select compression for a disk drive. As it turns out I must have been having a pleasant dream or mistakenly remembered the one for encryption and There was no such box. It's really strange. I have a strong recollection for seeing a box somewhere that had to be check to get data on a disk to be compressed. Sorry for the bad data. Anyway from the discussion, I am under the impression that btrfs uses compression by default for user's data files. If I am right will there be a way to turn that off? Have a Good Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
2020-07-20 @ 15:00 UTC - Fedora QA Meeting - Minutes
== #fedora-meeting: Fedora QA Meeting == Meeting started by adamw at 15:01:42 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2020-07-20/fedora-qa.2020-07-20-15.01.log.html . Meeting summary --- * Roll call (adamw, 15:01:54) * Previous meeting follow-up (adamw, 15:07:17) * no action items at last meeting (adamw, 15:08:19) * Fedora 33 status and Changes (adamw, 15:08:23) * Rawhide is mostly okay at the moment, aside from a few known issues that are on the blocker list (FreeIPA being broken etc.) (adamw, 15:08:51) * Several major changes have landed recently, including: (adamw, 15:09:16) * https://fedoraproject.org/wiki/Changes/SwapOnZRAM (adamw, 15:09:27) * https://fedoraproject.org/wiki/Changes/BtrfsByDefault (adamw, 15:09:34) * https://fedoraproject.org/wiki/Changes/UseNanoByDefault should land shortly (adamw, 15:15:57) * LINK: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/UXAX44ONG5ZZ2UKV5T63NVGZSWFOAH6G/ (adamw, 15:18:27) * tablepc was concerned about the swap-on-ZRAM Change constantly 'occupying' a chunk of system RAM, cmurf explained this is not how it works and there is not a constant sizable memory overhead, also clarified that it is not intended to compensate for performance issues in btrfs as tablepc assumed, the swap-on-zram and btrfs-by-default changes are independent (adamw, 15:29:19) * pwhalen noted that Everything netinst adopts the btrfs-by-default change which may be unexpected, we will flag this for further discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1857798 (adamw, 15:51:37) * Test Day / community event status (adamw, 15:52:07) * i18n Test Day will be 2020-09-08 (adamw, 15:56:23) * expect a virt test day soon (adamw, 15:56:27) * GNOME test week also being planned (adamw, 15:59:12) * Open floor (adamw, 15:59:27) Meeting ended at 16:02:48 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (73) * cmurf (69) * tablepc (33) * zodbot (12) * pwhalen (11) * sumantro (10) * lruzicka (8) * frantisekz (5) * coremodule (3) * Southern_Gentlem (2) * tflink (1) * bcotton (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Re: agenda for todays QA meeting
On 7/20/20 7:23 AM, pmkel...@frontier.com wrote: I just got around to figuring out what zram is. I see it's automatically set up when Anaconda sets up btrfs. It shouldn't have anything to do with btrfs. It's one of the changes to have it turned on by default. Look in the devel list archives for some huge threads on this. First a bit of background all the PCs (Fedora WS) I maintain are bought with lots of ram 8GB is the min. I don't think I've ever seen swap move off zero and no one has reported any sort of slowdowns. Yet we do lots of memory intensive things. Of course all this is with ext4. That is surprising. Usually at least something ends up in the swap. Now I see on my test machine (btrfs) that about 24% (2GB) of the 8GB of memory (according to monitor) (4GB according to disks) is dedicated to zram0. I imagine the difference in size reported to due to the compression used by zram. However there are two issues: Careful what you're using to measure with. The only accurate measurement is "zramctl". That will tell you exactly how much RAM the zram device is using. First I can't think of any good reason why I should need or want to have any of my ram dedicated to swapping or other things that speed up btrfs. We've been very happy with swap being on disk since it's never been seen to move off zero. You really need to read more about zram. There is no dedicated space for it. It only uses RAM as swap is needed. And it uses less RAM than the pages that are getting swapped out, so there's a net reduction in RAM usage without hitting the disk. Second, a few years back, I looked over some of the compression algorithms. The probability of loss or corruption was low, but non-zero. I'm sure they have improved, but I'll bet those probabilities are still non-zero. I was taught back in my early years at school that unnecessary risk is foolish risk. So I've always avoided using compression where ever I had an option. These compression algorithms have been tested very hard and are used everywhere. I've never seen mention of any corruption issues. I'm hoping someone can tell me I'm wrong and why, or that there's a way to opt-out of zram without a hit to performance when using btrfs. If you really want to disable zram (there's no reason to), I believe the simplest method is "touch /etc/systemd/zram-generator.conf". And it's nothing to do with btrfs. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
agenda for todays QA meeting
Let's talk about zram. I just got around to figuring out what zram is. I see it's automatically set up when Anaconda sets up btrfs. First a bit of background all the PCs (Fedora WS) I maintain are bought with lots of ram 8GB is the min. I don't think I've ever seen swap move off zero and no one has reported any sort of slowdowns. Yet we do lots of memory intensive things. Of course all this is with ext4. Now I see on my test machine (btrfs) that about 24% (2GB) of the 8GB of memory (according to monitor) (4GB according to disks) is dedicated to zram0. I imagine the difference in size reported to due to the compression used by zram. However there are two issues: First I can't think of any good reason why I should need or want to have any of my ram dedicated to swapping or other things that speed up btrfs. We've been very happy with swap being on disk since it's never been seen to move off zero. Second, a few years back, I looked over some of the compression algorithms. The probability of loss or corruption was low, but non-zero. I'm sure they have improved, but I'll bet those probabilities are still non-zero. I was taught back in my early years at school that unnecessary risk is foolish risk. So I've always avoided using compression where ever I had an option. If this is necessary to make btrfs work or get reasonable performance from it. That is a strike against btrfs. From this I conclude that to run btrfs on these machines and get the performance we're used to I have to up the minimum ram load to 12GB. Ram modules have a non-zero cost. Given the above this cost must be assigned to btrfs and are born by Fedora users. I'm hoping someone can tell me I'm wrong and why, or that there's a way to opt-out of zram without a hit to performance when using btrfs. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Fedora rawhide compose report: 20200720.n.0 changes
OLD: Fedora-Rawhide-20200719.n.0 NEW: Fedora-Rawhide-20200720.n.0 = SUMMARY = Added images:1 Dropped images: 5 Added packages: 0 Dropped packages:3 Upgraded packages: 36 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:276.87 KiB Size of upgraded packages: 2.47 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 141.38 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200720.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200719.n.0.iso Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200719.n.0.ppc64le.vmdk Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200719.n.0.ppc64le.raw.xz Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200719.n.0.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200719.n.0.ppc64le.qcow2 = ADDED PACKAGES = = DROPPED PACKAGES = Package: amqp-1:1.0-12.20150701svn1688630.fc32 Summary: The AMQP specification RPMs:amqp amqp-devel Size:53.18 KiB Package: csvdiff-0.3.1-12.fc33 Summary: Generate a diff between two CSV files on the command-line RPMs:csvdiff Size:28.65 KiB Package: jp2a-1.0.7-6.fc32 Summary: Small utility that converts JPG images to ASCII (text) using libjpeg RPMs:jp2a Size:195.03 KiB = UPGRADED PACKAGES = Package: Carla-1:2.2.0-0.1.rc1.fc33 Old package: Carla-1:2.2-1.beta1.fc33 Summary: Audio plugin host RPMs: Carla Carla-devel Carla-vst lv2-carla Size: 53.05 MiB Size change: 1.82 MiB Changelog: * Sun Jul 19 2020 Martin Gansser - 1:2.2.0-0.1.rc1 - Update to 2.2.0-0.1.rc1 Package: cmake-3.18.0-2.fc33 Old package: cmake-3.18.0-1.fc33 Summary: Cross-platform make system RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui cmake-rpm-macros Size: 56.25 MiB Size change: 1.05 KiB Changelog: * Sat Jul 18 2020 Igor Raits - 3.18.0-1.1 - Enable out-of-source builds by default * Sun Jul 19 2020 Neal Gompa - 3.18.0-2 - Make in-source builds behave like before Package: ditaa-0.10-11.fc33 Old package: ditaa-0.10-9.fc33 Summary: Diagrams Through ASCII Art RPMs: ditaa Size: 88.10 KiB Size change: -3.01 KiB Changelog: * Fri Jul 10 2020 Jiri Vanek - 0.10-10 - Rebuilt for JDK-11, see https://fedoraproject.org/wiki/Changes/Java11 * Sun Jul 19 2020 Terje Rosten - 0.10-11 - Add patch from Debian to build with JDK 10+ Package: dummy-test-package-crested-0-842.fc33 Old package: dummy-test-package-crested-0-835.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 59.23 KiB Size change: 456 B Changelog: * Sun Jul 19 2020 packagerbot - 0-836 - rebuilt * Sun Jul 19 2020 packagerbot - 0-837 - rebuilt * Sun Jul 19 2020 packagerbot - 0-838 - rebuilt * Sun Jul 19 2020 packagerbot - 0-839 - rebuilt * Sun Jul 19 2020 packagerbot - 0-840 - rebuilt * Sun Jul 19 2020 packagerbot - 0-841 - rebuilt * Mon Jul 20 2020 packagerbot - 0-842 - rebuilt Package: dummy-test-package-gloster-0-933.fc33 Old package: dummy-test-package-gloster-0-927.fc33 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 64.52 KiB Size change: 359 B Changelog: * Sun Jul 19 2020 packagerbot - 0-928 - rebuilt * Sun Jul 19 2020 packagerbot - 0-929 - rebuilt * Sun Jul 19 2020 packagerbot - 0-930 - rebuilt * Sun Jul 19 2020 packagerbot - 0-931 - rebuilt * Sun Jul 19 2020 packagerbot - 0-932 - rebuilt * Mon Jul 20 2020 packagerbot - 0-933 - rebuilt Package: fedora-obsolete-packages-33-17 Old package: fedora-obsolete-packages-33-15 Summary: A package to obsolete retired packages RPMs: fedora-obsolete-packages Size: 202.50 KiB Size change: 469 B Changelog: * Sun Jul 19 2020 Elliott Sales de Andrade - 33-16 - Bump Obsoletes for python2-beautifulsoup4 * Sun Jul 19 2020 Miro Hron??ok - 33-17 - Obsolete python2-pillow-devel (#1858557) - Bump version of python2-pillow-tk and -qt Package: giac-1.6.0.7-1.fc33 Old package: giac-1.5.0.85-3.fc33 Summary: Computer Algebra System, Symbolic calculus, Geometry RPMs: giac giac-devel giac-doc giac-xcas pgiac Size: 75.91 MiB Size change: -1.65 MiB Changelog: * Tue Jun 30 2020 Jeff Law - 1.5.0.85-4 - Fix broken configure test compromised by LTO * Sun Jul 19 2020 Antonio Trande 1.6.0.7-1 - Update to 1.6.0 sub-7 Package: git-2.28.0-0.1.rc1.fc33 Old package: git
