Announcement

Collapse
No announcement yet.

Linux 4.14 File-System Benchmarks: Btrfs, EXT4, F2FS, XFS

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

  • enihcam
    replied
    As per XFS wiki, consider changing the default CFQ I/O scheduler (for example to Deadline, Noop or BFQ) to enjoy all of the benefits of XFS, especially on SSDs.

    Leave a comment:


  • JustRob
    replied
    Originally posted by JustRob View Post
    Michael, can you add BCacheFS to the list?
    Also for those fans of ZFS is Lustre: http://lustre.org/download/ .

    NextPlatform wrote an article about Lustre on ZFS claiming huge performance increases: https://www.nextplatform.com/2017/01...ntinuing-work/ .

    Sometimes the increase is a measly 2x or 10x but there's a 80X Faster RAIDZ3 Reconstruction.

    This open source software has Intel backing with binaries available on their site for several distributions: https://wiki.hpdd.intel.com/display/PUB/Lustre+Releases .

    For those whom enjoy studying there's complete instructions for rolling your own: http://wiki.lustre.org/Compiling_Lustre .

    Incorporating both BCacheFS (which Michael is familiar with) and Lustre would provide two filesystems with the newest implementation of ZFS and it's features to add to the testing mix.

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by gadnet View Post
    why still avoiding ZFS
    it could be very cool to see how ZFS on linux do especialy on raid settings like raid1 or raid10
    comparaison to raid BTRFS, raid ZFS and mdadm raid + ext4/XFS..
    My best bet is that you have to compile ZFS yourself and Michael favors easy to automate tests.

    Leave a comment:


  • Ardje
    replied
    Originally posted by F.Ultra View Post
    If you move around PB of data on regular basis (as I do) then the differences are quite real, the benefits of the checksumming however outweigh the performance loss for me so BTRFS it is.
    Indeed. Btrfs is noticeably slower than ext4 in real life, but it has features that makes it faster in use than any other filesystem in the kernel.
    Like snapshots/clones. If you use btrfs as backing store for dirvish, it can automagically clone and make new backups, and just remove old snapshots "on-the-fly".
    Removing a snapshot will still take a few hours, but it will be backgrounded, whereas an rm -fr of a tree on ext4 can take more than 24 hours, just decreasing link counts.
    The lack of stability in high I/O pressure related loads prevented me to use it on anything else but backups of backups, as data loss due to btrfs self corruption was always imminent. Of course that was back in 2014. It might have changed in the mean time.
    And I always remember the time that a btrfs.fsck took 7 months, with 16GB of ram, 540GB of swap space, only to end in an out-of-memory. The meta data it was working on was 250GB, the total diskspace in use was 2T of the 8T or was it an array of 16T
    I think the lack of stability is also the reason why it was kicked from virtualization solutions.
    I hope someday it will be stable again. The fact that it can self scrub and test it's own data with the metadata checksums is pretty important in CDN kind of setups, where you have redundancy over multiple nodes, but to keep the cost down by having only one disk per node.

    Leave a comment:


  • gadnet
    replied
    why still avoiding ZFS
    it could be very cool to see how ZFS on linux do especialy on raid settings like raid1 or raid10
    comparaison to raid BTRFS, raid ZFS and mdadm raid + ext4/XFS..

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by pal666 View Post
    actually it was fastest on two tests and same on third one
    it is slow on non-real-life tests
    it does cow, so you disable cow on databases or vms
    BTRFS is slower on writes and often faster on reads which is consistent with it's design (COW) and major feature (Checksumming). It's of course also slower on real-life tests, it's just that few desktop users perform as much IO as Michael does in these tests so the differences will feel much less there. If you move around PB of data on regular basis (as I do) then the differences are quite real, the benefits of the checksumming however outweigh the performance loss for me so BTRFS it is.

    Leave a comment:


  • JustRob
    replied
    Michael, can you add BCacheFS to the list?

    Leave a comment:


  • flux242
    replied
    yeah, btrfs is slow in almost all test scenarios but blazing fast in real life! Is your tinfoil hat on?

    Leave a comment:


  • pal666
    replied
    Originally posted by sireangelus View Post
    why is btrfs so slow?
    actually it was fastest on two tests and same on third one
    it is slow on non-real-life tests
    it does cow, so you disable cow on databases or vms

    Leave a comment:


  • thelongdivider
    replied
    Originally posted by treba View Post
    Indeed. I hope it will get broader acceptance on desktop mashines, especially concerning updates. Roling back to a snapshot after a update failed is a huge thing. And subvolumes instead of partitions should saves so mich disk space, not to mention compression and deduplication.

    One thing I really miss is native encryption. It would be really cool to have an encryption setup similar ios. On desktop systems, which quite often only get locked but not turned off, full-disk-encryption becomes less and less save, as the keys stay in memory.
    With native encryption, it would be possible to keep the keys for files nessecary to unlock the computer in ram, while others can only be read when the password is entered again.
    ext4 and friends offers this already as android is moving to a similar encryption setup.
    It's the only feature I can think of that btrfs lacks compared to them.
    This is true. I have a 512 GB SSD, and not allocating space for partitions in advance makes it so that I have all 512 GB available to /home, /, /var, and /opt, while maintaining partition-like separation between them.

    Leave a comment:

Working...
X