No announcement yet.

Btrfs Seeing Some Nice Performance Improvements For Linux 5.9

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by vladpetric View Post
    Some of the benchmarks (e.g., sqlite, postgres) use fsync ... The degree to which they are sped up is TBD.
    some people are smart enough to not use postgres on cow fs. less smart ones look for bogus benchmarks


    • #32
      Originally posted by dev_null View Post
      This never happened with ext4.
      it happened with ext4 numerous times, just not with your data(or you aren't aware of it, since ext4 doesn't check whether it returns you back garbage instead of what you put there). i.e. your anecdotal evidence has zero weight


      • #33
        Originally posted by cynical View Post
        This makes me wonder whether I should use ZFS or Btrfs for my next Ubuntu install. I’m leaning towards ZFS because the official support is likely to be stronger.
        btrfs's official support comes from zfs official support comes from some garage


        • #34
          Originally posted by pal666 View Post
          some people are smart enough to not use postgres on cow fs. less smart ones look for bogus benchmarks
          Postgresql works just fine on zfs with some tuning, and you end up with better reliability. It may not be as fast as ext4, but that's not the only criteria.

          I would not use Postgresql on btrfs right now (something I've said before as well, in these forums), but that can still change if it gets its act together.

          Don't worry, I'm far more accomplished than you are.


          • #35
            MariaDB/InnoDB can be tuned nicely to run on COW filesystems.

            innodb-doublewrite = 0
            innodb_flush_method = O_DSYNC
            You may also look at things like

            Especially the following if you run on SSD:
            Last edited by S.Pam; 05 August 2020, 12:34 PM.


            • #36
              Originally posted by pal666 View Post
              nothing you listed requires it to be subvolume-specific. i.e. if you could put parity for whole fs on separate drives, it would work just as well(because all good things about subvolumes stem from single fact that they are not tied to partitions. as soon as you tie them, you don't need them)
              Yeah I understand what you mean and I agree that to tie them completely would not be that great. Putting a weight on them is better. E.g. prefer to store that subvolume on a fast set of disks, but necessarily set a hard limit. Disk groups could also be useful for auto-migrating/duplicating hot data to a cache group and similar stuff.



              • #37
                Originally posted by gnulinux82

                Have fun with your 128GB NMVe drive, bro.
                There all made in China if you want to know. Also I paid pretty top dollar for this one, no amazing unbelievable deal was to be had.


                • #38
                  They generally all ship from China originally. Even ones on Amazon unfortunately..

                  Non the less I'll be doing testing once I get it to ensure it has 2TB of REAL data storage and functions at the advertised 3300/3000MB/s