Announcement

Collapse
No announcement yet.

Btrfs Enjoys More Performance With Linux 6.3 - Including Some 3~10x Speedups

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

  • #31
    Originally posted by AdelKS View Post
    Does it need a freshly formatted BTRFS partition with Linux 6.3 to benefit of the new speedups and features ?
    I've got the same question. Does the "micro optimized b-tree key lookup" require a change to the file system, and if so, can it be done in place without reformatting?

    Comment


    • #32
      Should this be taken as a sign they actually intend to get raid5/6 to a production ready state?

      Comment


      • #33
        Originally posted by Mitch View Post
        I've seen movement from StratisD, but haven't yet seen checksums+ healing and I can't recall if transparent compression is in scope.

        And maybe BCacheFS will also mainline this year.

        It'll be interesting to see where these 3 projects land in the next few years and how they'll compare.
        Don’t count on using XFS (which stratis uses) for Steam, many 32bit games have compatibility issues.

        Comment


        • #34
          Originally posted by scottishduck View Post
          Should this be taken as a sign they actually intend to get raid5/6 to a production ready state?
          I don’t think raid5 and raid6 matter for btrfs as much as it does for other raid methods, because it isn’t a physical based raid, you can get pretty close with setting metadata to be dupped everywhere and using something like raid1c3 (I think it’s called) on btrfs which ensures the data is copied 3x onto 4 disk.

          this gets you the same redundancy as raid5/6, and some space advantage, although not as much as true raid5/6

          Comment


          • #35
            Originally posted by NobodyXu View Post
            brucethemoose Since when is data integrity not important?
            It is VERY important, but not for everything.... It is only important for data you care to not lose. So you can still use btrfs and whatnot on a separate backup disk and have your sensitive data secured. No reason to lose performance for the whole desktop. EXT4 is still king.

            Comment


            • #36
              Originally posted by TemplarGR View Post

              It is VERY important, but not for everything.... It is only important for data you care to not lose. So you can still use btrfs and whatnot on a separate backup disk and have your sensitive data secured. No reason to lose performance for the whole desktop. EXT4 is still king.
              if your data on ext4 get silently corrupted, your backup will contain corrupted data and you won't notice and maybe your last good copy got rotated from backups.
              if your data are on btrfs you can detect corruption very soon and restore from a good copy from the backup (or, if you have a redundant configuration, they'll be automatically fixed for you).

              Comment


              • #37
                Originally posted by waxhead View Post

                I have not tested and are biased towards BTRFS for the most part, but since reliability is not important (raid0) I am dead sure it is MD+ext4. However I would seriously look at md+XFS if speed is something you care about.
                I'd need just to combine at least two SSDs for heavy utilized multiuser build system. Reliability is not main concern because that system is not used for production builds. However any kind of striping would be beneficial to decrease wear leveling.

                Comment


                • #38
                  Originally posted by F.Ultra View Post
                  you also risk introduce errors because external software can add file, FiLE and fiLE and our application is quite screwed. Less error cases and higher performance to have the FS be caseless.
                  Which, tbf is also the case for native applications. tbh, I don't see any reason why case-sensitive file/directory names are desirable at all.
                  Of course, right now we need that, because of compatibility, but in the end, it would really be a good thing to slowly move away from that.
                  Why would I want to have File, file, FIle and FILe on my filesystem?
                  Isn't that just a recipe for disaster?

                  Comment


                  • #39
                    Originally posted by F.Ultra View Post
                    And honestly the features of btrfs is kinda lost on games from Steam since Steam calcs it's own checksums and can just download corrupted files anew.
                    That's true, although some btrfs features could be useful for the user data.
                    e.g. you could save the actual game files on ext4, but the user data, where e.g. your save games are stored you might want to keep on btrfs.
                    Which would also give you the possibility to easily backup these using the integrated snapshot functionality (many games these days support cloud saves, but not all of them).

                    Personally, if btrfs would support case fold, I would just use it for the steam library as well, because tbh filesystem performance is really overrated in the times of nvme devices that do 5GB/s. But that's just my personal preference.

                    Comment


                    • #40
                      I'm compiling a kernel now to try with these patches.

                      https://git.kernel.org/pub/scm/linux...it/?h=for-next

                      [Edit]
                      Errored during compilation. I'll give it another go when 6.2 has been upstreamed. As I tried it on 6.1
                      Last edited by Turbine; 21 February 2023, 06:07 AM.

                      Comment

                      Working...
                      X