Language Selection

English French German Italian Portuguese Spanish

Btrfs in Next Fedora

Filed under
Red Hat
  • Btrfs by default, the compression option

    Hi,

    The change proposal has a 'compression option' and we kinda need to get organized. https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression

    - Compression saves space, significantly reduces write amplification and therefore increases flash lifespan, and in some cases increases performance.
    - Desired but not a requirement of the change proposal.

    1. Goal: probably the goal performance wise is to perform as good or better than now. Is it OK if there's a write time performance hit for a small percent of folks, for a high value target like usr that isn't updated that often, and is also updated out of band (offline updates typically, but also isn't something directly related to the daily workload)? How to decide this?

    2. Benchmarking: this is hard. A simple tool for doing comparisons among algorithms on a specific bit of hardware is lzbench. https://github.com/inikep/lzbench How to compile on F32. https://github.com/inikep/lzbench/issues/69 But is that adequate? How do we confirm/deny on a wide variety of hardware that this meets the goal? And how is this test going to account for parallelization, and read ahead? Do we need a lot of data or is it adequate to get a sample "around the edges" (e.g. slow cpu fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow drive). What algorithm?

    3. Improvements and upgrades. We'll do plan A, but learn new things later, and come up with plan B. How do we get the plan A folks upgraded to plan B? Or just don't worry?

    4. The whole file system (using a mount option) or curated (using an XATTR set on specific "high value" directories)? This part is elaborated below.

    A. do this with a mount option '-o compress=zstd:1'
    - dilemma: it doesn't always lead to equal or better performance. On some systems and workloads, write performance is slightly reduced. What about LZO?

    B. do this with per directory XATTR
    - dilemma: the target directories don't exist at install time, depending on whether the installation is rsync, rpm, or unsquashfs based.

    C. do the install with '-o compres=zstd', then set XATTR post-install
    - dilemma: the installed files won't have XATTR set, only new files inherit; does a 'dnf update' overwrite files and therefore the XATTR is not inherited, or are they new files and do inherit the XATTR?

    D. Which directories? Some may be outside of the installer's scope.
    /usr /var/lib/flatpak
    ~/.local/share/flatpak
    /var/lib/containers/
    ~/.local/share/containers/
    ~/.var
    ~/.cache

    (Plausible this list should be reversed. While compressing ~/.cache may not save much space, it's likely hammered with more changes than other locations, hence more benefit in terms of reducing write amplification.)
    For reference, the above is mostly from the description in the RFE bug attached to the feature's tracker bug. But I think it's best to have most discussion here and leave the bug for implementing+testing the implementation details. https://bugzilla.redhat.com/show_bug.cgi?id=1851276

    Thanks,

    --
    Chris Murphy

  • Fedora Developers Evaluating Compression Options For Btrfs-By-Default Proposal

    The proposal for using Btrfs by default on the Fedora desktop is gaining a fair amount of traction and interest from the community and could possibly move ahead but further testing and decisions are still to be made.

    First of all, today marks a Fedora Btrfs test day for those wanting to help in evaluating this change proposal. Check it out if you have spare system(s) and interested in helping make the decision whether Fedora desktop spins should transition from EXT4 to Btrfs by default.

  • Btrfs to be the Default Filesystem on Fedora? Fedora 33 Starts Testing Btrfs Switch

    While we’re months away from Fedora’s next stable release (Fedora 33), there are a few changes worth keeping tabs on.

    Among all the other accepted system-wide changes for Fedora 33, the proposal of having Btrfs as the default filesystem for desktop variants is the most interesting one.

Fedora Linux Desktop To Switch From EXT4 To Btrfs Filesystem

  • Fedora Linux Desktop To Switch From EXT4 To Btrfs Filesystem By Default

    A few months ago, with the release of the latest Fedora 32, the development of the next stable version Fedora 33 started. As the development cycle of 33 is still underway, a new proposal was sent to bring major changes to the Fedora desktop variants.

    The proposal includes transitioning from ext4 to Btrfs filesystem by default for Fedora Workstations and Spins across x86_64 and ARM architectures. Subsequently, Fedora developers also organized a test day on July 8, 2020, to experiment with the new filesystem features.

Colin Walters: On BTRFS (in Fedora by Default)

  • Colin Walters: On BTRFS

    There is this terminology in the industry of pets vs cattle – I once saw a talk that proposed "elephants vs ants" instead which is more appealing. Lately I tend to use "disposable" or "reprovisionable" for the second term.

    I mentioned above I reprovision my workstation periodically, but it’s still somewhat of a "pet". I don’t have everything in config management yet (and probably never will); I change things often enough that it’s hard to commit to 100% discipline to record every change in git instead of just running a CLI or writing a file. But I have all the important stuff. (And I take backups of data separately of course.)

    For people who don’t have much in configuration management – the server or desktop system that has years of individually built up changes (whether from people doing things manually over ssh or interactively via a GUI like Cockpit, being able to take a filesystem snapshot of things is an extremely compelling feature.

    Another great BTRFS-style use case is storing data like your photos on a local drives instead of uploading them to the cloud, etc.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Games: DRAG, Valve Index kit and Inscryption

  • DRAG | Linux Gaming | Ubuntu 20.04 | Native

    DRAG running natively through Linux.

  • Sci-fi racer with fancy 4-point physics 'DRAG' is now in Early Access

    Orontes Games have finally unleashed DRAG, their sci-fi racer with advanced 4-point physics into Early Access. Note: key provided to GOL by the developer. Introducing what they say is a "new kind of vehicle-physics", their 4-way contact point traction technology (or 4CPT-technology for short) simulates every component of the vehicles in real time. The result is supposed to give you "realistic, dynamic" behaviour with a full damage model, so expect to see wheels flying across your screen when in multiplayer.

  • My experiences of Valve's VR on Linux

    As the proud and excited owner of a shiny new Valve Index kit to go with my almost-new all-AMD rig, I thought I’d outline the journey to getting it all working, exclusively on Linux. Now bear in mind that I’m not amazingly Linux-savvy. I’ve been using it since the early 2000’s, sure, and full time, exclusively, since 2013, but I’m not very interested in learning the guts of this stuff. I’m extremely technical as a network nerd, but my O/S is just a tool to let me run cool things. I want to be a “normal” consumer of that O/S and if things don’t work out of the box, I take a dim view of it and I don’t have a lot of patience for terminal hacks or “compiling my own kernel”.

  • Inscryption from the developer of Pony Island has a new trailer

    Inscryption from Daniel Mullins Games (Pony Island, The Hex) sounds absolutely wild and it's got a brand new trailer but we've got quite some time to wait on it. Based upon the title Sacrifices Must Be Made, which Mullins made for the Ludum Dare 43 Game Jam, Inscryption is described as an "inky black card-based odyssey that blends the deckbuilding roguelike, escape-room style puzzles, and psychological horror into a blood-laced smoothie".

LibreOffice 7.0: A week in stats

One week ago, we announced LibreOffice 7.0, our brand new major release. It’s packed with new features, and has many improvements to compatibility and performance too. So, what has happened in the week since the announcement? Let’s check out some stats… These are just stats for our official downloads page, of course – some Linux users will have acquired the new release via their distribution’s package repositories. Read more Also: LibreOffice 7.0 Is Already Approaching A Half-Million Downloads

LibreELEC (Leia) 9.2.4

LibreELEC 9.2.4 (Leia) has arrived based upon Kodi v18.8. Changes since 9.2.3: firmware fixes for RPi (fixes booting issues) Kodi 18.8 Kodi 19 Matrix: We have currently no plans yet to create an official Alpha release of LE10 with the Alpha version of Kodi 19. Due the drawn out release cycle of Kodi and the experiences from the past few years we are waiting a bit longer to avoid major problems. Nightly builds could be downloaded like usual, that includes the latest unstable development snapshot of LE10/Kodi19. Read more

Android Leftovers