Announcement

Collapse
No announcement yet.

Another Look At The Bcachefs Performance on Linux 6.7

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

  • #61
    Originally posted by curfew View Post
    Ah, the denial is strong here. Pointless bickering about everything except the topic of the article. Bcachefs performed poorly and no-one is ready to acknowledge it.
    this is considered poorly? Bcachefs beat BTRFS in 2/5 benchmarks here excluding the thread increases since they followed trend. and this isn't even a release kernel yet

    Comment


    • #62
      The introduction page says that the 64 core 7980x is running at 8.21GHz. That seems to be on the high side of things, 3.2GHz is more reasonable, typo?

      Comment


      • #63
        Only XFS for PostgreSQL

        Comment


        • #64
          Originally posted by Quackdoc View Post

          I don't think a test on ram is "useless" but I don't think there is too much value in it either aside from "huh that's neat". Not to mention it there is little point in actually optimizing for a ram only situation (there is some don't get me wrong) for the vast majority of filesystems, so they would not be indicative of the "best preformance" anyways.

          I do think test's in isolation are useless because they will never be indicative of what a filesystem will actually be put through, there are thousands upon thousands of potential variables
          Thanks for clarifying. I do agree with you, testing in RAM is not a substitute for testing on real hardware as it is all a orchestrated "dance" between all the software (and hardware) layers and that is what matters in the end. I do still think that resting in RAM will identify (obvious) algorithmic problems, but then again the real answer to what is best is probably each and anything in between, that is a bit too complex tough.

          http://www.dirtcellar.net

          Comment


          • #65
            Would have been interesting to see if there's a performance difference using 4096 block size like the other tested filesystems.

            Comment


            • #66
              Originally posted by zexelon View Post

              I have used XFS for years on both work stations, servers and clusters. I moved over to it from EXT4 specifically for some of its more edge case performance. I would say it is definitely on par with EXT4 from a reliability point and edges it out in performance in quite a few use cases.

              XFS is no where near as advanced as ZFS, btrfs or bcachefs, but it can be built on top of LVM quite nicely to achieve similar (though clunkier than say ZFS) setups.
              What I would like to see is a comparison between XFS and and ZFS/BTRFS in functional-equivalence scenarios.

              The reason to run ZFS is to exploit mirroring/RAID, ability to extend volumes, etc. Why not do an XFS+LVM+mdraid (not sure how you would set this up) versus ZFS/BTRFS native configuration? That would be very interesting for users considering options beyond ext4.

              I hope Michael likes this article idea and picks it up.

              Comment


              • #67
                Just curious why BcacheFS block size is set to 512 bytes when all the other filesystems are set to 4096 bytes? Wouldn't it make sense to set them all to the same block size? And, really, 4096 bytes should be the minimum block size for any filesystem to allow for easier migration to Advanced Format drives going forward (for those still using spinning rust for storage).

                Comment


                • #68
                  Originally posted by cynic View Post
                  bitrotting is not a bug of the filesystem.
                  next time, instead of showing off and call other people conspiracy theorist, just use a search engine to at least undertand what you are talking about.
                  I don't believe I was showing off, not sure how that would work when I'm asking you a question. You seem to be the one trying to show off some sort of superior knowledge, but my probing question has apparently revealed that you do, in fact, have zero experience with the problem you are scare-mongering about. As expected. Since you are such an expert on 'bitrot and ext4' searches, I'm sure you realize that there are no reports of it actually occurring with ext4. There are quite a few articles questioning whether bitrot is a real phenomenon at all, or just a conspiracy.

                  Comment


                  • #69
                    Originally posted by akarypid View Post

                    What I would like to see is a comparison between XFS and and ZFS/BTRFS in functional-equivalence scenarios.

                    The reason to run ZFS is to exploit mirroring/RAID, ability to extend volumes, etc. Why not do an XFS+LVM+mdraid (not sure how you would set this up) versus ZFS/BTRFS native configuration? That would be very interesting for users considering options beyond ext4.

                    I hope Michael likes this article idea and picks it up.
                    Michael This would be awesome to see! Including bcachefs (or bca-chefs) if you will! I run a lot of servers on XFS/LVM combo, but have started to experiment on a non-essential system with ZFS. Having a head to head of these 4 systems would be really helpful to some real world sysadmins.

                    Comment


                    • #70
                      Originally posted by andyprough View Post

                      I don't believe I was showing off, not sure how that would work when I'm asking you a question. You seem to be the one trying to show off some sort of superior knowledge, but my probing question has apparently revealed that you do, in fact, have zero experience with the problem you are scare-mongering about. As expected. Since you are such an expert on 'bitrot and ext4' searches, I'm sure you realize that there are no reports of it actually occurring with ext4. There are quite a few articles questioning whether bitrot is a real phenomenon at all, or just a conspiracy.
                      Zero of those articles can be serious. Bitrot is a physical phenomenon that is no mystery at all, bits on the drive are not carved in stone (and even things carved in stone experiences bitrot eventually). There is nothing in other filesystems, like EXT4, that detects bitrot. Ofc bitrot is extremely rare since HDDs and SSDs don't store bits as such but instead use various forms of error correcting codes but if people are now claiming that there have never been unrecoverable files on storage media then I have more than one bridge to sell to those.

                      Originally posted by phoenix_rizzen View Post
                      Just curious why BcacheFS block size is set to 512 bytes when all the other filesystems are set to 4096 bytes? Wouldn't it make sense to set them all to the same block size? And, really, 4096 bytes should be the minimum block size for any filesystem to allow for easier migration to Advanced Format drives going forward (for those still using spinning rust for storage).

                      Since Michael used the default setting it looks like bcachefs reads the disk wrong (some ssd:s report a sector size of 512B for "compatibility reasons") while they other filesystems doesn't. Because Bcachefs should default to 4k blocks according to the docs so this really sounds like a bug.
                      Last edited by F.Ultra; 02 December 2023, 01:49 AM.

                      Comment

                      Working...
                      X