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

Software: Bashtop, Cointop and Auto-cpufreq

  • Bashtop – A Resource Monitoring Tool for Linux

    Bashtop is a terminal-based resource monitoring utility in Linux. It’s a nifty command-line tool that intuitively displays statistics for your CPU, memory, running processes, and bandwidth to mention just a few. It ships with a game-inspired and responsive terminal UI with a customizable menu. Monitoring various system metrics is made easy by the neat arrangement of various display sections. With Bashtop, you can also sort processes, as well as easily switch between the various sorting options. Additionally, you can send SIGKILL, SIGTERM, and SIGINT to the processes that you want.

  • Tracking Your CRYPTO INVESTMENTS Is Dead Simple With Cointop
  • Automatic CPU Speed & Power Optimizer Auto-cpufreq 1.2 Released

    Auto-cpufreq, automatic CPU speed & power optimizer for Linux to improve battery life, released version 1.2 with AMD support. Different to cpufreq indicator and / or TLP, Auto-cpufreq automatically make “cpufreq” related changes based on active monitoring of laptop’s battery state, CPU usage and system load. Ultimately allowing you to improve battery life without making any compromises.

today's howtos

Security, Fear, Uncertainty, Doubt

SUSE/OpenSUSE: Tumbleweed, YaST and Corporate Stuff

  • Skopeo, xxHash, GCC 10.2 are Among Updates in Tumbleweed

    openSUSE Tumbleweed had continuous daily snapshots with a handful of software package updates this week. Many minor-version updates and one major-version update became available to Tumbleweed users and the newest snapshot, 20200804, updated the iso-codes package, which lists country, language and currency names; the new 4.5.0 version updated translations and the subdivision names for Belarus. The Greybird Geeko theme was updated to improve contrast of gtk2 selection background color. The desktop calculator qalculate was updated to version 3.12.0 and improved exact simplification of roots. The fast hash algorithm xxhash 0.8.0 stablized the XXH3. Both libyui-ncurses and ncurses had minor updates. The snapshot is trending stable with a rating of 97, according to the Tumbleweed snapshot reviewer.

  • Digest of YaST Development Sprint 105

    Although a significant part of the YaST Team is enjoying their well deserved summer vacations, the development wheel keeps turning. During the latest two weeks we have fixed quite some bugs in several parts of (Auto)YaST. But listing fixed bugs it’s quite boring, so let’s focus on more interesting stuff we have also achieved.

  • Open Source for the Edge at IoT World

    As technologies converge to drive new innovation at the edge, organizations are working together more than ever to pave the road forward by combining the likes of 5G, AI/ML, Embedded Systems, High Performance Computing, Kubernetes, private/public environments and more. Companies are bringing specific domain expertise to the table, and SUSE is uniquely positioned with 28 years of Linux and open source expertise to serve as the foundation for developing, distributing and managing edge systems and the critical workloads they will support.

  • SUSE Partner Summit – Coming to a digital platform in mid-September!