3 ms·

At this point in time, they still can't be compared, because btrfs is still not [considered] production-ready, and subject to significant changes (also performa

At this point in time, they still can't be compared, because btrfs is still not [considered] production-ready, and subject to significant changes (also performance-related). This is especially important because on use cases where performance differences are significant, that is, not on general desktop usage, the maturity of the FS is funamental, and btrfs is discouraged right now.

derefr 12y ago
There are many situations where performance is important, and durability is... not. For example, ephemeral CoreOS cloud instances running Docker containers: they use lots of copy-on-write layers, but they don't actually need to persist any state across reboots (the layers may as well be stored in volatile memory.) Btrfs is perfectly "production-ready" for this particular use-case, so a [current] performance comparison would be pretty useful.
- ryao 12y ago
  I am working on ZFS support for CoreOS. A snapshot of my WIP proof of concept was posted by my employer yesterday: https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tutorial-667/docs/experimental/zfs-on-coreos.rst https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tuto... CoreOS uses btrfs as its rootfs. I imagine that the CoreOS developers managed to avoid issues like ENOSPC by virtue of not writing to their rootfs very much. I did not have that luxury since I compiled a Gentoo GNU userland on top of it during the course of development. I encountered numerous ENOSPC errors on btrfs when developing the ZFS port to CoreOS and even hit ENOSPC errors when trying to correct the btrfs ENOSPC errors with `btrfs balance /`. I would not consider btrfs ready for production use, but your mileage will vary.
  - simoncion 12y ago
    When were you hitting these ENOSPC errors, and what kernel were you using when you hit them? $ df -h . Filesystem Size Used Avail Use% Mounted on /dev/dm-1 42G 41G 280M 100% /home $ btrfs fi df . Data, single: total=40.48GiB, used=40.21GiB System, single: total=4.00MiB, used=12.00KiB Metadata, single: total=1.01GiB, used=649.18MiB $ uname -r 3.15.2-hardened As you can see, I've been working with a pretty much full btrfs volume. It used to be TERRIBLE to deal with btrfs in such a situation, but I haven't had an ENOSPC issue in ages.
    - ryao 12y ago
      The Gentoo Prefix boootstrap on a developer image: https://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap.xml https://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap.x... CoreOS uses Linux 3.15.y.

derefr 12y ago

There are many situations where performance is important, and durability is... not. For example, ephemeral CoreOS cloud instances running Docker containers: they use lots of copy-on-write layers, but they don't actually need to persist any state across reboots (the layers may as well be stored in volatile memory.) Btrfs is perfectly "production-ready" for this particular use-case, so a [current] performance comparison would be pretty useful.

ryao 12y ago
I am working on ZFS support for CoreOS. A snapshot of my WIP proof of concept was posted by my employer yesterday: https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tutorial-667/docs/experimental/zfs-on-coreos.rst https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tuto... CoreOS uses btrfs as its rootfs. I imagine that the CoreOS developers managed to avoid issues like ENOSPC by virtue of not writing to their rootfs very much. I did not have that luxury since I compiled a Gentoo GNU userland on top of it during the course of development. I encountered numerous ENOSPC errors on btrfs when developing the ZFS port to CoreOS and even hit ENOSPC errors when trying to correct the btrfs ENOSPC errors with `btrfs balance /`. I would not consider btrfs ready for production use, but your mileage will vary.
- simoncion 12y ago
  When were you hitting these ENOSPC errors, and what kernel were you using when you hit them? $ df -h . Filesystem Size Used Avail Use% Mounted on /dev/dm-1 42G 41G 280M 100% /home $ btrfs fi df . Data, single: total=40.48GiB, used=40.21GiB System, single: total=4.00MiB, used=12.00KiB Metadata, single: total=1.01GiB, used=649.18MiB $ uname -r 3.15.2-hardened As you can see, I've been working with a pretty much full btrfs volume. It used to be TERRIBLE to deal with btrfs in such a situation, but I haven't had an ENOSPC issue in ages.
  - ryao 12y ago
    The Gentoo Prefix boootstrap on a developer image: https://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap.xml https://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap.x... CoreOS uses Linux 3.15.y.