Announcement

Collapse
No announcement yet.

Btrfs Seeing Some Nice Performance Improvements For Linux 5.9

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

  • theriddick
    replied
    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

    Leave a comment:


  • theriddick
    replied
    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.

    Leave a comment:


  • waxhead
    replied
    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.

    Leave a comment:


  • S.Pam
    replied
    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.

    Leave a comment:


  • vladpetric
    replied
    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.

    Leave a comment:


  • pal666
    replied
    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

    Leave a comment:


  • pal666
    replied
    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

    Leave a comment:


  • pal666
    replied
    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

    Leave a comment:


  • pal666
    replied
    Originally posted by waxhead View Post
    Right now there is not much of a difference, but in the long run this could allow for parity based raid where the stripes are on fast groups of disks and the parity on slower devices. And a disk failure could use a different group as spare space or redundant space. It works also make it easier to isolate metadata on its own controller for example. Plus migrationomigration data would not be across filesystems. It all boils down to flexibility.
    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)
    Last edited by pal666; 04 August 2020, 07:47 PM.

    Leave a comment:


  • theriddick
    replied
    I'm going to setup btrfs on my 2TB NVMe and test it under windows (free driver) and linux. Will be interesting, assuming my drive even turns up from China..................

    Leave a comment:

Working...
X