Announcement

Collapse
No announcement yet.

Btrfs Async Buffered Writes Slated For Linux 6.1 - 2x Throughput Improvement

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

  • #11
    Originally posted by kylew77 View Post

    Lost my whole FS converting from ext4 to BTRFS going from Debian Wheezy to Jessie a few years back. Glad they finally put a warning on the ext4 to BTRFS converter that it is not guaranteed to work. My mom's linux computer also had weird issues on BTRFS that were not reproducible on ext4 and in that case I started with a BTRFS system! Too many weird cases with BTRFS when almost everyone I've talked to who has used it has had some weird issue.
    Well, that's all ancient history and that's not the case anymore. So...

    Comment


    • #12
      Originally posted by kylew77 View Post
      Lost my whole FS converting from ext4 to BTRFS going from Debian Wheezy to Jessie a few years back. Glad they finally put a warning on the ext4 to BTRFS converter that it is not guaranteed to work.
      Was it confirmed that was the fault of the converter?

      FWIW, I'm very cautious around filesystems. I use rsync to migrate data between them, although that obviously requires intermediate storage (hopefully via a backup), if your new filesystem is going on the same drive.

      Originally posted by kylew77 View Post
      My mom's linux computer also had weird issues on BTRFS that were not reproducible on ext4 and in that case I started with a BTRFS system! Too many weird cases with BTRFS when almost everyone I've talked to who has used it has had some weird issue.
      Not me, FWIW. I've now used it more than any other FS, both at home and at work. When performance demands it, the other filesystem we use is XFS.

      Sometimes, an issue can disappear for reasons not related to the filesystem itself. I once ran badblocks on a drive and was getting a large amount of errors. On a hunch, I stopped it and ran fstrim. Afterwards, badblocks reported no more errors. If I had wiped the filesystem and repopulated the drive with something else, I think most mkfs now automatically do a fstrim of the unused space. So, the problem would've disappeared, leaving me to incorrectly blame BTRFS. I'm not saying your mom's machine didn't have some real BTRFS problem, but there cases where problems are mis-attributed to the filesystem.

      Something else I wonder is how many "problems" people report with BTRFS are errors detected by its checksum that would've gone silently undetected by non-checksumming filesystems. In such cases, the problem is actually faulty hardware that BTRFS is designed to protect you against.
      Last edited by coder; 25 September 2022, 12:45 PM.

      Comment


      • #13
        Originally posted by user1 View Post
        Maybe I'm not well informed about file systems in general, but if btrfs really is buggy and unstable as many say, then how come Facebook uses it at its data centers? I mean isn't it a mission critical use case?
        Those people are just spreading unwarranted FUD.
        While admittedly not always the fastest, BTRFS nowadays is very much ok for any workload.
        Last edited by _ReD_; 25 September 2022, 12:52 PM.

        Comment


        • #14
          Originally posted by Developer12 View Post
          Great, now I can loose my data to bugfs twice as fast.
          Unlike most other filesystems BTRFS will tell you that your data has gone bananas. If you have a redundant setup your data will be fixed. What is better? A filesystem that tells you that your hardware is failing or a filesystem that chugs along happily returning potentially garbled data....

          http://www.dirtcellar.net

          Comment


          • #15
            Maybe ext4 can add async read and writes and then become ext5?

            Comment


            • #16
              Just rewrite the filesystem in Rust and after that we can hopefully finally drop Ext4 and XFS and all the other legacy crud. One FS to rule them all!

              Comment


              • #17
                Originally posted by curfew View Post
                Just rewrite the filesystem in Rust and after that we can hopefully finally drop Ext4 and XFS and all the other legacy crud. One FS to rule them all!
                man, it's getting hard to recognize trolls from genuine Rust fanboys!

                Comment


                • #18
                  Originally posted by uid313 View Post
                  Maybe ext4 can add async read and writes and then become ext5?
                  The filesystem is defined by the format of the data on the device. Async reads/writes are a matter of the implementation. So, adding these to ext4 (if it doesn't already have them) wouldn't make it anything other than ext4. Same way that adding them to BTRFS doesn't make it anything other than BTRFS.

                  Comment


                  • #19
                    Originally posted by _ReD_ View Post

                    Those people are just spreading unwarranted FUD.
                    While admittedly not always the fastest, BTRFS nowadays is very much ok for any workload.
                    Just need to make sure you're using RAID1, not 5 or 6.

                    Comment


                    • #20
                      Originally posted by uid313 View Post
                      Maybe ext4 can add async read and writes and then become ext5?
                      ...I dont think thats really applicable?


                      But in any case, ext4, xfs and f2fs all bench much faster than filesystems like btrfs or zfs. Its apples an oranges, as you are paying for all those features with overhead that the btrfs devs are indeed working to minimize.
                      Last edited by brucethemoose; 25 September 2022, 02:57 PM.

                      Comment

                      Working...
                      X