Announcement

Collapse
No announcement yet.

Btrfs Sees A Number Of Improvements With Linux 5.8

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

  • Btrfs Sees A Number Of Improvements With Linux 5.8

    Phoronix: Btrfs Sees A Number Of Improvements With Linux 5.8

    SUSE's David Sterba was quite punctual in getting all of the Btrfs file-system updates submitted quickly for the newly-opened Linux 5.8 kernel merge window...

    http://www.phoronix.com/scan.php?pag...s-Improvements

  • #2
    dunno if this will make it into 33 https://fedoraproject.org/wiki/Chang...ystemSnapshots

    Comment


    • #3
      - Changing behavior so when a subvolume deletion fails over lack of space, the file-system is not turned read-only.
      I fail to see how this could possibly happen. Can anyone explain that to me?

      Comment


      • #4
        Originally posted by archkde View Post

        I fail to see how this could possibly happen. Can anyone explain that to me?
        it is due to the COW design: deleting files and subvolumes requires some amount of free space

        Comment


        • #5
          Originally posted by archkde View Post

          I fail to see how this could possibly happen. Can anyone explain that to me?
          First you write new metadata, then you delete the old - that's the way btrfs is keeping state consistent at all times.

          In addition, deleting old stuff causes released free space information to be written into 'free space tree' that makes allocating new files faster. But that also takes some extra space and needs to be written before old stuff is deleted (i.e. it is overlapping with deletion).

          All of that is a problem only with the extreme case when filesystems are 99.99% full
          ... or when free space is not regularly balanced.
          Last edited by pkese; 06-02-2020, 11:33 AM.

          Comment


          • #6
            Btrfs has been working very reliably for me for a long while now, except for 1 bug:

            Sometimes (rarely) on unclean shutdown of my laptop, if the power is interrupted due to lack of battery, on next boot the kernel refuses to mount the filesystem readwrite, showing an error about failing to recover the transaction log.

            I work around this by booting into Windows and mounting my Linux partition readwrite with the WinBtrfs driver. It fixes the issue, and then Linux boots normally after reboot.

            Yes, ironically, I am using Windows to fix my Linux filesystem.

            Comment


            • #7
              ... in addition: when you have multiple snapshots, you'd expect that 99% of those snapshot files would be the same across snapshots. So only a small portion of those files get deleted.
              However all metadata needs to be updated with new information e.g. that all remaining files are now referenced N-1 times. That requires quite some writes (depending on the structure of subvolume being snapshotted/deleted).

              Comment


              • #8
                Originally posted by pkese View Post

                First you write new metadata, then you delete the old - that's the way btrfs is keeping state consistent at all times.

                In addition, deleting old stuff causes released free space information to be written into 'free space tree' that makes allocating new files faster. But that also takes some extra space and needs to be written before old stuff is deleted (i.e. it is overlapping with deletion).

                All of that is a problem only with the extreme case when filesystems are 99.99% full
                ... or when free space is not regularly balanced.
                I know that deletion on CoW filesystems can cause a temporary increase in used space this way. But IIRC, Btrfs introduced a "GlobalReserve" to make sure that this temporary space is always available.

                Comment


                • #9
                  Originally posted by tajjada View Post
                  Btrfs has been working very reliably for me for a long while now, except for 1 bug:

                  Sometimes (rarely) on unclean shutdown of my laptop, if the power is interrupted due to lack of battery, on next boot the kernel refuses to mount the filesystem readwrite, showing an error about failing to recover the transaction log.

                  I work around this by booting into Windows and mounting my Linux partition readwrite with the WinBtrfs driver. It fixes the issue, and then Linux boots normally after reboot.

                  Yes, ironically, I am using Windows to fix my Linux filesystem.
                  Did you bring that issue up to the btrfs mailing list? It sounds like a firmware bug.

                  I've never experienced RO btrfs filesystems after unclean shutdowns, except for a particular set of drives. Checking the mailing list, those were know to corrupt the filesystem in one way or another. Specifically, I'm talking about a spinning WD Black SATA drive, two Green ones, and two SSD whose brand I can't remember (those SSD were a major fiasco).

                  Comment


                  • #10
                    Originally posted by tajjada View Post
                    Btrfs has been working very reliably for me for a long while now, except for 1 bug:

                    Sometimes (rarely) on unclean shutdown of my laptop, if the power is interrupted due to lack of battery, on next boot the kernel refuses to mount the filesystem readwrite, showing an error about failing to recover the transaction log.
                    Are you using a recent kernel version (or with btrfs fixes backported)?
                    My laptop battery dies often without warning but I never had this issue with btrfs. (I'm running Fedora, so I always have fairly recent kernels).

                    Also, every time it happens I do (as suggested) a full scrub and I never get any corruption.



                    Comment

                    Working...
                    X