Announcement

Collapse
No announcement yet.

Btrfs Seeing Some Nice Performance Improvements For Linux 5.9

Collapse
X
 
  • 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

    Comment


    • #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

      Comment


      • #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 kernel.org. zfs official support comes from some garage

        Comment


        • #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.

          Comment


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

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

            https://mariadb.com/kb/en/innodb-sys...lush_neighbors
            Especially the following if you run on SSD:
            https://mariadb.com/kb/en/innodb-sys...db_io_capacity
            https://dev.mysql.com/doc/refman/5.7/en/innodb-configuring-io-capacity.html
            Last edited by S.Pam; 05 August 2020, 12:34 PM.

            Comment


            • #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.

              http://www.dirtcellar.net

              Comment


              • #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.

                Comment


                • #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

                  Comment

                  Working...
                  X