5 ms·

It has been successfully ported to FreeBSD and now there is a functional Linux ZFS kernel port too So this is a port and therefor CDDL licesned and no able to

by steve19 16y ago

It has been successfully ported to FreeBSD and now there is a functional Linux ZFS kernel port too So this is a port and therefor CDDL licesned and no able to be merged into the mainline Linux Kernel, right? Is ZFS still a hot commodity with BTRfs just around the corner?

patrickgzill 16y ago
I would say yes, given my experience with ZFS of a number of years in production.
- mhansen 16y ago
  Please explain?
  - bensummers 16y ago
    Would you like to be one of the first to discover a data-loss bug in brtfs? If not, you probably want the tried and trusted ZFS.
    - spahl 16y ago
      I wouldn't really call this ZFS port "tried and trusted". :-D
      - bensummers 16y ago
        I wouldn't use it on Linux! Obviously Solaris would be the 'best' place to use it. But even after a port, the underlying FS will have many more years of production use than brtfs. You might find bugs in the interface between the kernel and ZFS, but hopefully they wouldn't mess with any of the core fs code.
      - sigil 16y ago
        Fully agree there. FreeBSD has had ZFS for 3+ years, and I still see some serious issues once in a while. Beware all new filesystems.
  - patrickgzill 16y ago
    It makes a lot of the common sysadmin tasks a whole lot easier. For instance, creating raid sets - by default it works with whole disks, which is exactly what you want 99% of the time (but you can specify a partition if you really want to). Want to check whether there is a data corruption error? "zpool scrub poolname" and it will go through all the disks on that pool, using the built-in ECC to verify that the data on the disks is OK. If not, it will try to fix it. "zpool status -v" lists all the disks, which mirrors or RAID sets each is part of, and when the last scrub was performed, along with errors or ECC problems. The one suggestion I would make for the btrfs guys is to really work on making the CLI commands simple and intuitive.
    - ssmoot 16y ago
      Minor correction, Scrub just rewrites all data. And since ZFS is copy-on-write and compares new blocks to old, you'll find corruption or bad blocks that way. Also, since ZFS doesn't dedupe (just don't use it) or compress at rest, a scrub is the practical way to apply changes to those settings to the existing blocks already on disk.
      - patrickgzill 16y ago
        Good point, this post talks about their need to rewrite the scrub code to fix a bug and make it faster. http://blogs.sun.com/ahrens/entry/new_scrub_code http://blogs.sun.com/ahrens/entry/new_scrub_code
lmz 16y ago
It will be interesting to see what happens with btrfs when Oracle now has Solaris and ZFS.
- nailer 16y ago
  Chris Mason pasted about this: according to him, nothing (remember BtrFS is btree based, ZFS isn't).
  - lmz 16y ago
    This post[1] maybe? I just have some difficulty believing Oracle would continue to fund btrfs when they have ZFS. Then again, the code is already out there, the developer can simply move to Red Hat / IBM / Canonical / wherever and continue working if funding is pulled. [1]: http://www.linux-foundation.org/weblogs/amanda/2009/06/22/a-conversation-with-chris-mason-on-btrfs-the-next-generation-file-system-for-linux/ http://www.linux-foundation.org/weblogs/amanda/2009/06/22/a-...
    - nailer 16y ago
      Why? Asides from the BtrFS having btrees and some (acknowledged by the ZFS developers) better design decisions (see the btrfs wikipedia page), ZFS keeps Solaris customers locked into Solaris and away from Linux.
      - lmz 16y ago
        Oracle owns Solaris now. Why would they not want to lock their customers into Solaris?
        nailer 16y ago
        Yes. We agree.
wazoox 16y ago
Actually you can't even distribute binaries at all. Btrfs is quite far from being "around the corner". A solid, dependable filesystem must be in the wild for a couple of years to be called "production ready".
- nailer 16y ago
  RHEL6 is shipping btrfs as a 'tech preview' (like, say, SystemTap used to be). So yeah, maybe 2 years, maybe 18 months, but the point is: the time starts pretty close to now.
  - wazoox 16y ago
    Given that I actually was hurt by bugs in filesystems as old and stable as xfs, I'd still wait a little more than that before using btrfs in a large scale. I'll build and set up about 1.2 PB of storage this year....
ssmoot 16y ago
I've heard about btrfs being "just around the corner" for a good while now. ZFS on Nexenta and even FreeBSD is pretty robust. It's a great storage platform. I wouldn't let waiting on a stable btrfs make my SAN/NAS decisions for me. The other concern in that realm is that when you're centralizing storage concerns to lower costs, boost performance and increase reliability you don't want software issues or corruption to take down your entire business. ZFS can be a painful enough learning curve when it comes to that environment. I wouldn't trust btrfs until it's been stable for a couple years there. And outside of that environment, there are plenty of good stable alternatives for the DAS space. While ZFS is nice there, and I'm sure btrfs would be as well, that's not the bread and butter for these systems.
- Andys 16y ago
  I believe btrfs comes with Ubuntu 10.10
  - alphabeat 16y ago
    Can you provide a source for that? Sounds exciting.
    - spahl 16y ago
      It was supposed to get into 10.10 for testing but according to the blueprint it was deferred (https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-btrfs-support https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-...).
rm-rf 16y ago
I still see btrfs as years behind zfs as measured strictly by maturity (not features), and therefore consider it to be at least a few years away from being usable in situations where an advanced file system really matters (mission critical databases, 30+TB file systems, etc.) ZFS has been around 4-5 years, yet in the last few months we hit a severe data loss bug (ZIL corruption) and a service affecting ZFS cache performance bug (ARC cache maintenance routine with math error). I'd assume that btrfs will have similar teething pains.

by steve19 16y ago

patrickgzill 16y ago

I would say yes, given my experience with ZFS of a number of years in production.

mhansen 16y ago
Please explain?
- bensummers 16y ago
  Would you like to be one of the first to discover a data-loss bug in brtfs? If not, you probably want the tried and trusted ZFS.
  - spahl 16y ago
    I wouldn't really call this ZFS port "tried and trusted". :-D
    - bensummers 16y ago
      I wouldn't use it on Linux! Obviously Solaris would be the 'best' place to use it. But even after a port, the underlying FS will have many more years of production use than brtfs. You might find bugs in the interface between the kernel and ZFS, but hopefully they wouldn't mess with any of the core fs code.
    - sigil 16y ago
      Fully agree there. FreeBSD has had ZFS for 3+ years, and I still see some serious issues once in a while. Beware all new filesystems.
- patrickgzill 16y ago
  It makes a lot of the common sysadmin tasks a whole lot easier. For instance, creating raid sets - by default it works with whole disks, which is exactly what you want 99% of the time (but you can specify a partition if you really want to). Want to check whether there is a data corruption error? "zpool scrub poolname" and it will go through all the disks on that pool, using the built-in ECC to verify that the data on the disks is OK. If not, it will try to fix it. "zpool status -v" lists all the disks, which mirrors or RAID sets each is part of, and when the last scrub was performed, along with errors or ECC problems. The one suggestion I would make for the btrfs guys is to really work on making the CLI commands simple and intuitive.
  - ssmoot 16y ago
    Minor correction, Scrub just rewrites all data. And since ZFS is copy-on-write and compares new blocks to old, you'll find corruption or bad blocks that way. Also, since ZFS doesn't dedupe (just don't use it) or compress at rest, a scrub is the practical way to apply changes to those settings to the existing blocks already on disk.
    - patrickgzill 16y ago
      Good point, this post talks about their need to rewrite the scrub code to fix a bug and make it faster. http://blogs.sun.com/ahrens/entry/new_scrub_code http://blogs.sun.com/ahrens/entry/new_scrub_code

lmz 16y ago

It will be interesting to see what happens with btrfs when Oracle now has Solaris and ZFS.

nailer 16y ago
Chris Mason pasted about this: according to him, nothing (remember BtrFS is btree based, ZFS isn't).
- lmz 16y ago
  This post[1] maybe? I just have some difficulty believing Oracle would continue to fund btrfs when they have ZFS. Then again, the code is already out there, the developer can simply move to Red Hat / IBM / Canonical / wherever and continue working if funding is pulled. [1]: http://www.linux-foundation.org/weblogs/amanda/2009/06/22/a-conversation-with-chris-mason-on-btrfs-the-next-generation-file-system-for-linux/ http://www.linux-foundation.org/weblogs/amanda/2009/06/22/a-...
  - nailer 16y ago
    Why? Asides from the BtrFS having btrees and some (acknowledged by the ZFS developers) better design decisions (see the btrfs wikipedia page), ZFS keeps Solaris customers locked into Solaris and away from Linux.
    - lmz 16y ago
      Oracle owns Solaris now. Why would they not want to lock their customers into Solaris?
      - nailer 16y ago
        Yes. We agree.

wazoox 16y ago

Actually you can't even distribute binaries at all. Btrfs is quite far from being "around the corner". A solid, dependable filesystem must be in the wild for a couple of years to be called "production ready".

nailer 16y ago
RHEL6 is shipping btrfs as a 'tech preview' (like, say, SystemTap used to be). So yeah, maybe 2 years, maybe 18 months, but the point is: the time starts pretty close to now.
- wazoox 16y ago
  Given that I actually was hurt by bugs in filesystems as old and stable as xfs, I'd still wait a little more than that before using btrfs in a large scale. I'll build and set up about 1.2 PB of storage this year....

ssmoot 16y ago

I've heard about btrfs being "just around the corner" for a good while now. ZFS on Nexenta and even FreeBSD is pretty robust. It's a great storage platform. I wouldn't let waiting on a stable btrfs make my SAN/NAS decisions for me. The other concern in that realm is that when you're centralizing storage concerns to lower costs, boost performance and increase reliability you don't want software issues or corruption to take down your entire business. ZFS can be a painful enough learning curve when it comes to that environment. I wouldn't trust btrfs until it's been stable for a couple years there. And outside of that environment, there are plenty of good stable alternatives for the DAS space. While ZFS is nice there, and I'm sure btrfs would be as well, that's not the bread and butter for these systems.

Andys 16y ago
I believe btrfs comes with Ubuntu 10.10
- alphabeat 16y ago
  Can you provide a source for that? Sounds exciting.
  - spahl 16y ago
    It was supposed to get into 10.10 for testing but according to the blueprint it was deferred (https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-btrfs-support https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-...).

rm-rf 16y ago

I still see btrfs as years behind zfs as measured strictly by maturity (not features), and therefore consider it to be at least a few years away from being usable in situations where an advanced file system really matters (mission critical databases, 30+TB file systems, etc.) ZFS has been around 4-5 years, yet in the last few months we hit a severe data loss bug (ZIL corruption) and a service affecting ZFS cache performance bug (ARC cache maintenance routine with math error). I'd assume that btrfs will have similar teething pains.