Announcement

Collapse
No announcement yet.

XFS / EXT4 / Btrfs / F2FS / NILFS2 Performance On Linux 5.8

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

  • #31
    Originally posted by Michael View Post

    Default mount options were used, no manual options were set.
    Yes, we know. But it is not a good choice.

    Comment


    • #32
      Originally posted by Vistaus View Post

      I thought it was supposed to be slow? Fellow Phoronix members keep saying that ext4 is supposed to be slow because the focus is on stability.
      They shouldn't be so much difference between xfs && ext4. And it's almost impossible than btrfs is so much faster than ext4, because it's a cow filesystem.

      It could be great to have same benchmark with same hardware with differents kernels to be able to compare.

      Comment


      • #33
        My experience with btrfs is: If there is a checksum failure in the middle of your mp3 library it's time to see if your backups work: fsck most probably won't help you here.
        With ext4 the same failure might go unnoticed for years until you recognize that your favorite radio play now is remixed with blind melon's first (and by itself excellent) album on all backups that still work. But the root problem in both cases might be non-ecc ram, anyway...

        Comment


        • #34
          Originally posted by Spam View Post

          Turn of atime. Don't turn off cow, it is a bad recommendation as it reduces the integrity.
          I suggested turning it off selectively just on stuff that recreated if bad (cache) and logs.

          Comment


          • #35
            Originally posted by Spam View Post

            Yes, we know. But it is not a good choice.
            For what Michael intended to test, it is.

            Comment


            • #36
              Originally posted by gunterkoenigmann View Post
              My experience with btrfs is: If there is a checksum failure in the middle of your mp3 library it's time to see if your backups work: fsck most probably won't help you here.
              With ext4 the same failure might go unnoticed for years until you recognize that your favorite radio play now is remixed with blind melon's first (and by itself excellent) album on all backups that still work. But the root problem in both cases might be non-ecc ram, anyway...
              My experience with btrfs is that with a RAID1 the scrub finds the problem in your MP3 files, corrects it and everything continues as normal. Then I repeatedly had the same problem with the one drive. It acted like writing the bad blocks healed it but later the same blocks would be bad again. Replaced the drive, no more problems.

              On a single drive laptop SSD btrfs found all kinds of metadata sequence and checksum errors after a battery-empty power-off. The drive had obviously not written all the data it claimed it had written. Had to recover from backups, although btrfs restore did work to copy off the data from the drive. There were no significant differences from the last backup though.

              Comment


              • #37
                Ubuntu and no zfs vs btrfs I see ~

                Comment


                • #38
                  Originally posted by elatllat View Post
                  Ubuntu and no zfs vs btrfs I see ~
                  Current OpenZFS in Ubuntu doesn't support Linux 5.8 kernel, looks like some compat patches were added to OpenZFS Git just a few weeks ago. Plus this was a comparison of mainline file-systems with a focus on Btrfs.
                  Michael Larabel
                  http://www.michaellarabel.com/

                  Comment


                  • #39
                    [QUOTE=Vistaus;n1190960]
                    Originally posted by andyprough View Post

                    Using uMatrix an Phoronix, eh? Don't you trust Michael?
                    Graphs are presented from openbenchmarking.org. Since that's different from the page's domain, it gets blocked by pretty much anything. For me (even if I disable ad blocking here), it was NoScript. Fixable, but as shown here, can lead to confusion.

                    Comment


                    • #40
                      Originally posted by Old Grouch View Post
                      I don't use NILFS2 for performance, but for its unparalleled snapshotting capabilities. It is also reasonably SSD friendly. But I fully appreciate that my use-case is not mainstream, and I make no bold claims that NILFS2 is the 'one true filesystem - I just find it useful for my purposes. I continue to be very happy to have a choice of filesystems, and grateful that people develop them to meet specific needs. People who need better performance than I do will obviously make a different choice, and that is good.

                      Thank you to Michael for giving people the interesting comparisons.
                      My last test with NILFS2, not merely "benchmarks", but actually trying to use its features showed a lot of kernel module crashing. What kernel are you using? Just curious. What I like about NILFS2 (if it is stable, which I doubt) is that you can come the closest to having a true versioning filesystem vs typical snapshotting.

                      I got frustrated by it recently. So, while I like some of its features, my fear is that is has gone into decay with regards to maintenance and testing.

                      Comment

                      Working...
                      X