Announcement

Collapse
No announcement yet.

Fedora 33 Making Progress With Their Btrfs-By-Default On The Desktop

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Duff~ View Post
    I really hope there's a way to set compression since the very beginning (with Anaconda), so you don't have to compress everything AFTER the installation.
    I'm expecting (hoping) that there will be another internal update by August or September that incorporates it.

    Comment


    • #12
      Originally posted by Zan Lynx View Post

      What sort of "flags" in /etc/fstab are you thinking of? I use btrfs on most of my Fedora systems and all of them have various flags. My entry for "/" has a subvol=root,noatime setting, for example.
      Code:
      subvol=root,compress=zstd,ssd_spread,noatime,space_cache 0 0

      Comment


      • #13
        So will the default be btrfs on cryptsetup (on lvmcache if ssd/hd combo detected)?

        Comment


        • #14
          Originally posted by Mario Junior View Post

          Code:
          subvol=root,compress=zstd,ssd_spread,noatime,space_cache 0 0
          The only reason that could fail is if zstd compression requires a kernel module that isn't being built into the initramfs. You could force dracut to include it. Read "man dracut" and add it to the dracut.conf file.

          Comment


          • #15
            Originally posted by Mario Junior View Post
            Call me when you implement the BTRFS partitioning available in OpenSUSE and when you allow adding the flags for BTRFS BEFORE installing the system and when the system allows you to use flags in fstab, as currently, the system will not start if there are any flags for btrfs in fstab .
            With BTRFS the important flags (compression type, space_cache etc) are persistent.

            Comment


            • #16
              Originally posted by ALRBP View Post

              I know this proposition does not come from Redhat, but I did not know that Fedora was independent enough to take decisions opposed to those of Redhat.
              I haven't seen anything that indicates that Red Hat is opposed to this change *for* Fedora. There have been some discussions around handling say blocker bugs etc but those are reasonable concerns and it appears that Facebook is willing to dedicate some resources for this. Other volunteer contributors have stepped in to shepherd this change as well

              Comment


              • #17
                So can you actually know how much space you have left and does deletion actually work?

                Comment


                • #18
                  Originally posted by pc777 View Post
                  So can you actually know how much space you have left and does deletion actually work?
                  This entirely depends on your definition of "work."

                  Generally with CoW filesystems or LVM snapshots the answer is "No." You cannot know how much space is left and you cannot rely on deletion to "work."

                  That is because with shared references and snapshots you have to go to a ton of extra work to determine if a file deletion will free any space. Since it might exist in multiple snapshots and reference copies, deleting one might not free any space at all.

                  The "space left" calculation is tough too. With btrfs the amount of metadata used by a file will be hard to predict. If you're using compression, the amount a file will compress is hard to predict.

                  Then there's features like "autodefrag." I use it on my NAS hard drive storage array, because without it the performance some things goes to the dogs. However, a "defrag" operation can split copies from reference copies (like snapshots) and so a disk operation might write 4K into the middle of a database file, and then surprise! autodefrag rewrote 8 MB of the file and your 4K write to an existing file suddenly used 8 MB more disk space.

                  Another thing about deletion that confuses some people. Many filesystems, not just btrfs, queue deletion up in the background. That means you can delete a big file, or a subvolume or a snapshot, and it appears to go away. However, the actual delete operation may take minutes and you won't get the disk space back until it finishes.

                  Comment


                  • #19
                    Originally posted by Mario Junior View Post
                    when the system allows you to use flags in fstab, as currently, the system will not start if there are any flags for btrfs in fstab .
                    i have any flags for btrfs in fstab with no issues(subvol=)

                    Comment


                    • #20
                      Originally posted by ALRBP View Post
                      I did not know that Fedora was independent enough to take decisions opposed to those of Redhat.
                      basically, you sourced your information from some garbage bin

                      Comment

                      Working...
                      X