Announcement

Collapse
No announcement yet.

Btrfs Has Many Nice Improvements, Better Performance With Linux 5.11

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

  • #61
    Originally posted by cynic View Post

    I'll try to make it simple so that you can understand, ok?

    more fragmentation => more metadata => bigger fs trees => more time required to traverse the trees + more lock contentions => performance penality.

    as said, you don't have to pay for mechanical delay, still, fragmentation causes performance panalities with SSD too.
    Yeah, I get that but you also make it sound like metadata is equal or larger in size than actual data itself.. In such case, whats the fucking point of the file system? Otherwise the space metadata takes under itself should be small enough to be near irrelevant compared to normal seek-time penalties.

    Comment


    • #62
      Originally posted by aht0 View Post

      Yeah, I get that but you also make it sound like metadata is equal or larger in size than actual data itself.. In such case, whats the fucking point of the file system? Otherwise the space metadata takes under itself should be small enough to be near irrelevant compared to normal seek-time penalties.
      where exactly did I make it sound such a stupid thing like "metadata is larger in size than actual data itself"?
      metadata doesn't have to be larger than data to slow the things down. They're just different stuff and used in different ways.

      in btrfs the basic data structure are trees, that references the actual data on the disk. Every operation you make on data requires one or more reads operations on one or more of the trees and eventualy a write (ore more) operation on one (or more) of the trees.

      the bigger the trees are, the more expensive those operation are. Also, longer operations increase the likehood that concurrent processes incurs in exclusive locking of the trees.

      Comment


      • #63
        I hope this optimizations are better than those of 5.10 which cause a 500% to 2000% performance regression w/ BTRFS https://youtu.be/3sK0moxJGrE

        Comment


        • #64
          Originally posted by rene View Post
          I hope this optimizations are better than those of 5.10 which cause a 500% to 2000% performance regression w/ BTRFS https://youtu.be/3sK0moxJGrE
          I just watched it quickly so maybe I missed it, but it seems that you didn't tried other FS.
          How do you know that it is a btrfs issue and not, for example, an USB issue?

          Comment


          • #65
            Originally posted by cynic View Post

            I just watched it quickly so maybe I missed it, but it seems that you didn't tried other FS.
            How do you know that it is a btrfs issue and not, for example, an USB issue?
            I tested a fresh NVMe and it was 5x slower, too - which is why I wrote 500 to 2000% Bisecting that takes a whole afternoon or so, does someone pay me to clean up after $$$.$$$ cooperate regression developers?

            Comment


            • #66
              Originally posted by rene View Post

              I tested a fresh NVMe and it was 5x slower, too - which is why I wrote 500 to 2000% Bisecting that takes a whole afternoon or so, does someone pay me to clean up after $$$.$$$ cooperate regression developers?
              i'll ask it again: have you tested other FSs?
              if not, how do you know it's a btrfs-related issue and not something else?

              Comment


              • #67
                Originally posted by cynic View Post

                i'll ask it again: have you tested other FSs?
                if not, how do you know it's a btrfs-related issue and not something else?
                it's funny how everyone always things the other are stupid noob idiots:

                # mkfs.ext4 /dev/mapper/test
                # mount /dev/mapper/test /mnt/
                # time tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst
                real 0m5.002s
                user 0m1.942s
                sys 0m3.753s

                so yes, still a btrfs regression. I'll ask again: who pays me now to bisect this well payed upstream developer bug and regression?

                Comment


                • #68
                  Originally posted by rene View Post

                  it's funny how everyone always things the other are stupid noob idiots:

                  # mkfs.ext4 /dev/mapper/test
                  # mount /dev/mapper/test /mnt/
                  # time tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst
                  real 0m5.002s
                  user 0m1.942s
                  sys 0m3.753s

                  so yes, still a btrfs regression. I'll ask again: who pays me now to bisect this well payed upstream developer bug and regression?
                  well, if everybody thinks you're stupid maybe you should improve your communication skill, don't you think?

                  also, stop asking for money. Nobody asked you to make that test.

                  If upstream developer are well payed, that means that they offer VALUE to their company.
                  stop complaining: if you are worth money, just get hired by those company.
                  if they won't hire you, then your time is not worth.

                  Comment


                  • #69
                    Originally posted by cynic View Post

                    well, if everybody thinks you're stupid maybe you should improve your communication skill, don't you think?

                    also, stop asking for money. Nobody asked you to make that test.

                    If upstream developer are well payed, that means that they offer VALUE to their company.
                    stop complaining: if you are worth money, just get hired by those company.
                    if they won't hire you, then your time is not worth.
                    I did take a test, they broken my systems. I did not ask them to break each major Linux kernel release in different ways. But the small independent developers constantly can to the regression fixing those big cooperations leave behind, and forums likes these don't even recognize all the hard work that goes into this.

                    Comment


                    • #70
                      Originally posted by rene View Post

                      I did take a test, they broken my systems. I did not ask them to break each major Linux kernel release in different ways. But the small independent developers constantly can to the regression fixing those big cooperations leave behind, and forums likes these don't even recognize all the hard work that goes into this.
                      hey, this is the deal in open source. You get to use the work of these big corporations at no financial cost - good for you. But when it breaks, well, you have to put in some work, or wait until they fix it... For them, they have to spend time and effort collaborating with others, have to do maintenance & bugfixing on things they don't care for and have to take the needs and requirements of others into account but in exchange they get 'free' testing from users and developer input from others.

                      We all give some and get some. It is always a compromise and never perfect, but it's great you and perhaps others put in the work to bisect the problem - now one of those evil corporate developers used his christmas days to find and code a solution, so I guess that goes to show they are humans who care about what they do, not just stupid corporate drones, right?

                      Comment

                      Working...
                      X