10 ms·

ZFS on Linux 0.6.1 released: Ready for wide scale deployment

209 points by iso8859-1 14y ago

dkhenry 14y ago
So the two things I don't see are a comparison with BTRFS in terms of speed, and stability. I know ZFS is cool, but while we were waiting for it BTRFS got pretty darn good. I know ZFS has some additional features that BRTFS doesn't have, but If I have to use a unstable or slow filesystem to get those features when I could use by perfectly stable and fast filesystem while I wait for a few nice features I am going to say ZFS has missed its oppertuinity
- wazoox 14y ago
  People love to harp about the benefits and wonders of ZFS, but they often forgot to mention its limitations: most features have an impact on performance, memory consumption is ginormous, IO performance is generally not great (lower than with "simpler" FS), and managing your pools isn't that easy once you get serious about it.
  - johnbellone 14y ago
    Not to mention the whole lack of an upstream. But all that aside ZFS was great when it was first introduced a few years back, especially with Sun backing OpenSolaris, but we've been jerked around for a few years. A ran a few ZFS pools on Linux a few builds ago and it was quite stable then. For something like a home storage system where I do not care about all the shortfalls vs. BTRFS I would reach to ZFS just because its what I know. For something that needs to be enterprise I'd hire someone that knows much more about it than me :).
    - dmpk2k 14y ago
      we've been jerked around for a few years Oracle's ZFS (and Solaris) fork is a deadish end. Most of the interesting action the past couple years has been happening among a collection of illumos (including critical ZFS members formerly from Sun), FreeBSD, OSX and even Linux hackers. I don't follow their activities closely, except to observe that they've been anything but idle. A lot of work has happened in the meantime, and continues. Hopefully one shows up to comment about it.
      - newman314 14y ago
        List of different versions of ZFS https://en.wikipedia.org/wiki/ZFS#Release_history https://en.wikipedia.org/wiki/ZFS#Release_history
      - natermer 14y ago
        Oracle's ZFS is now different then BSD/Linux ZFS. They have become incompatible file systems because Oracle has picked up their ball and taken it back home. For OSS ZFS the only upstream is 'collection of Illlumos'
      - johnbellone 14y ago
        I was running OpenIndiana for awhile at home before I just got tired of trying to hack together a bunch of patches. The problem with having a project that is pseudo OSS is that you can never actually use it seriously, its never reliable and for the most part its going to end in slow quiet death. In my opinion there are a were only a handful of reasons to use Solaris: Oracle, SPARC, ZFS and dtrace. The only reason to use it nowadays is because you can't scale x86 and need big iron for Oracle et al.
        dmpk2k 14y ago
        Unrelated to the topic at hand, but I've been happy with SmartOS. It's firmly and solely an OSS server OS, it's easy to use, many of the uglier Solaris legacy bits have been sanded off, and it has a decent package system (pkgsrc). My earlier experiences with Solaris and OpenSolaris were mixed. SmartOS has been uniformly positive. Perhaps give it a try, although be aware that it (like everything illumos) is picky about the hardware.
  - trotsky 14y ago
    Performance seems ok to me. 6x500gb 7.2k sata raid10 + 96gb ssd, 8gb ram. Run began: Fri Mar 29 08:32:24 2013 Include fsync in write timing Include close in write timing Command line used: iozone -ec -r 32 -s 16380m -l 2 -i 0 -i 1 -i 8 Throughput test with 2 processes Each process writes a 16773120 Kbyte file in 32 Kbyte records Parent sees throughput for 2 initial writers = 996073.19 KB/sec Avg throughput per process = 499898.70 KB/sec Parent sees throughput for 2 rewriters = 216128.36 KB/sec Avg throughput per process = 108075.14 KB/sec Parent sees throughput for 2 readers = 1232245.62 KB/sec Avg throughput per process = 616353.25 KB/sec Parent sees throughput for 2 re-readers = 1240045.15 KB/sec Avg throughput per process = 620251.62 KB/sec
    - dekhn 14y ago
      that's really not so impressive. you're just dumping extents down on an empty filesystem and re-reading them. you're really just measuring the fact that the FS isn't particularly getting in the way of using your hardware. Note also that rewriting drops to 108M/sec, which is pretty unimpressive.
      - trotsky 14y ago
        216M/sec - rewrite is suffering from a striding mismatch there with the COW, bs is 32k while stripe is 128k. Consumer uses 1M. I'm wondering which volume manager and fs under linux you'd expect better performance from in this configuration?
  - craigyk 14y ago
    Yeah... what are you talking about? Enormous memory consumption = deduplication? Otherwise it doesn't seem enormous too me. Sure ZFS made a lot of departures from the standard toolset with all its own stuff... but that stuff is better once you learn it. I can easily get 600MB+/sec reads and writes on my pools with are pretty commodity stuff. One of my pools is 95% full, which is high, and I just tested it and got over ~100MB/sec write ~150MB read.... good enough for me. (Oh, and I just checked, it was scrubbing) Here are my little ZFS peeves: 1. you can't grow raidZ vdevs. Reduces flexibility. 2. I wish there was a version of scrub that rebalanced data across vdevs. By comparison BTRFS is nice, but nowhere close to ZFS. Last I saw a BTRFS scrub consists of cat'ing every file to null... which doesn't even cover the FS and metadata.
  - glabifrons 14y ago
    "memory consumption is ginormous" Yes, it will use whatever memory you allow it to, but this is purely dynamic just as caching is in Linux. If you're not talking about the ARC, but about deduplication, of course it uses more memory - how would it not? "IO performance is generally not great (lower than with "simpler" FS)" This is sounding troll-ish, as that statement equates to: A filesystem that checksums all data and metadata and performs copy-on-write to protect the integrity of the on-disk state at all times is slower than a filesystem that does neither. Well, of course. But do those "simpler FS" have the ability to massively negate that effect by use of an SSD for the ZIL and L2ARC? There have been many articles showing higher throughput with large, slow 5400RPM drives combined with an SSD ZIL & L2ARC massively outperforming much faster enterprise drives. "managing your pools isn't that easy once you get serious about it" I'm fairly stunned by this statement, as I've yet to see an easier, more elegant solution for such a task. Before ZFS, I liked VXVM with VXFS, but I now consider it obsolete. Linux's LVM is downright painful in comparison. I've yet to play with btrfs, so I'll bite my tongue on what I've read so far on it. The deep integration of volume and pool management directly with the filesystem, essentially making them one and the same, is simply beautiful. Having these things separate (md, LVM, fs) after years of using ZFS seems so archaic and awkward to me. Disclosure: 100% of my ZFS experience has been on Solaris (10-11.1) and OpenSolaris/Nevada. I've not tried it on Linux, yet.
- kev009 14y ago
  Btrfs is actually a sordid state of affairs. It's been "two years out" for five years, which seems very disingenuous looking back. Groundbreaking FS development follows a pretty regular formula. 10 years seems to be the magic number. Major functionality (i.e RAID 5) is still just landing and has glaring issues. It's just now a couple years out. Meanwhile, ZFS has over 10 years of history, stably implements most of Btrfs _planned_ features, and has battle tested deployments. Granted, the SPL for Linux adds variables, but there are some big users of this particular project. So I approach Btrfs with the exact opposite mindset. It's guilty until innocent despite some FUD from the Linux camp early on that has settled down a bit since Oracle now has it's hands on both.
  - simplexion 14y ago
    i.e. == that is. e.g. = example. RAID5 is not major functionality, it should no longer exist.
    - Dylan16807 14y ago
      Can you explain why you feel that way? ZFS has intelligently managed RAID that keeps the performance penalty minimal. I'd rather have multiple-redundancy parity than 2x mirroring, and it takes less space.
      - gtirloni 14y ago
        ZFS' raid-z is nothing but pain. Does it have standard raid-5 now?
        simplexion 14y ago
        There is RAID-Z2 which allows for 2 discs to fail and RAID-Z3 which allows for 3. Problem is rebuild time is still slow. I wouldn't recommend to use RAID-Z1.
  - dkhenry 14y ago
    This is why people think BTRFS isn't any good, because someone waltses up and says yeah well it doens't have XXX feature which only _one_ other filesystem has so its clearly lacking and immature. The truth it it works great its sufficently fast and has been stable for years. Yes it doesn't have Raid5 or Raid Z if you would like and I can't import and export pools the way I can in ZFS, but honestly if you jumping on a FS that has been marked stable for all of two days on Linux and your reasoning is you can't do software raid on the other one then best of luck to you.
- antonios 14y ago
  Let me understand: You claim that ZFS is the unstable or slow filesystem, and that BTRFS, which is not even yet marked as stable by its developers is the perfectly stable and fast one? That seems an opposite way of thinking.
  - icebraining 14y ago
    Not ZFS, but ZFS for Linux.
- brokenparser 14y ago
  I tried resizing btrfs recently, my file came out truncated :(
- __david__ 14y ago
  > I know ZFS is cool, but while we were waiting for it BTRFS got pretty darn good. My own anecdotal evidence is that btrfs is not ready for prime time. I ran a couple btrfs file systems from kernel about 2.6.30 to 3.4 and finally determined that my system was so slow because of btrfs. I switched to xfs and an operation that used to take weeks (literally) now takes hours. Perhaps it's gotten significantly better in the last few revisions but I'd use caution if you want to use btrfs and still have good performance.
- 65a 14y ago
  I'm getting +20k IOPs and nearly 1GB/sec read/write out of a mirror, something like 40K 1.5GB/sec out of a mirror+stripe on ZFS under FreeBSD. Disks are either 2x256GB SSD or 4x128GB SSD. Meanwhile BTRFS was so slow on random IO I had to toss it out in favor of the less reliable JFS or EXT4 on Gentoo. Don't use RAIDZ if you want performance with ZFS however, and you need to set it up twice before you get how to performance tune it.
silveira 14y ago
What about the license compatibility?
- yankcrime 14y ago
  First answer in the FAQ: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
- mhurron 14y ago
  It looks like very similar issues on the use end to the nvidia binary driver. Can't ship it in Linux but nothing (legally) prevents end users from incorporating it.
  - lmickh 14y ago
    My concern with the license isn't legal so much as pain of administration. Maybe I'm just old fashion or lazy, but I prefer not to have to check my kernel repo against my kernel module repo to make sure they play nice. It is so much easier when you can just get it as part of the kernel. That is the reason why I avoid the Nvidia binary driver as well.
    - dpe82 14y ago
      If you're on Ubuntu, there's an apt package available in ZFS On Linux project's ppa. It downloads the source, builds it against your installed kernel and installs it. Rebuilds on any kernel update. Very handy. https://launchpad.net/~zfs-native/+archive/stable https://launchpad.net/~zfs-native/+archive/stable
- merijnv 14y ago
  The thing with both GPL and CDDL is that they both put restrictions on how you are allowed to distribute the program/source. i.e. you can't legally distribute code that has both GPL and CDDL parts. However, neither license puts restrictions on (end-user) use, which means that as long as you distribute the bits separately, running them together is perfectly fine. Which means (as their FAQ states) that while it can't ship as part of the kernel, there's no reason end-users wouldn't be allowed to load a separately distributed module into their kernel.
joosters 14y ago
Never mind all the promised wondrous features of ZFS, what are the recovery / fsck tools like? If the data recovery tools aren't mature, reliable and useful, then I'd advise anyone to stay away from a filesystem, no matter how world-ready the underlying FS code is. I'm probably biased; but I got screwed using ReiserFS. It was fast and great, but one day something went wrong and then I found that the reiserfsck program was practically useless. Very little work had been done on it, so any small inconsistencies in the FS meant your data was toast. Sure, keep backups and all that, but just be aware how important a good fsck tool is.
- jiggy2011 14y ago
  My understanding is that ZFS does a lot of healing itself on the fly. When you access a block, the block is checked against a checksum stored elsewhere on disk. If the block is bad, it is restored from a replica (so it's advisable to have 2 disks) while the original is healed. On writes ZFS also checks that each written block is valid before committing the new block to the filesystem. In the event of a bad write the new block is not committed and the old block remains, blocks are written originally to a separate area of the disk.
  - joosters 14y ago
    Yes, and those are good features. But there's still plenty of room for errors. Bugs in the code, bad interactions with hardware, etc. Those are areas where ZFS is likely to be just as vulnerable as other file systems. More so, in fact, given the code size/complexity and its (relative) immaturity. I suspect (but I have no data!) that the majority of times that users have file system corruption and need to run fsck is due to bad software behaviour, and not failing disks.
    - jiggy2011 14y ago
      ZFS itself has been around for a while, was originally part of Solaris IIRC. It's using it on Linux that's new. If you have a bad software write, ZFS should be able to detect that in the same way it would a hardware error since the checksums won't match. Also worth noting that the checksums are themselves checksummed in a merkle tree. It also has a tool called "scrub" which can check data integrity without unmounting the disk. Of course if your filesystem has buggy code for checksumming/repair then you are boned whatever.
runako 14y ago
If it's ready for wide scale deployment, I wonder why the team decided against signaling that by calling it 1.0 instead of 0.6.1. A version number < 1 makes me think the developers still think it's pre-release quality. That may not be the case here, but it makes me wonder.
- aneth4 14y ago
  My thoughts exactly. If you're going to declare something production ready, but don't have the nuts to call it 1.0, I don't believe you. Maybe 0.6.1 just has a nice ring that 1.0 doesn't quite get.
- prakahsurya 14y ago
  No, I can assure you we definitely do not think it's "pre-release" quality. I work closely with Brian Behlendorf, and I'm sure he would not have made the stable release if he thought it wasn't ready for prime time. It's a little disheartening to see people pay so much attention to a fictitious number, which really has no regard to the actual state of the code/project. Whether v1.0 or v0.1 was used, the quality of the release would not differ any.
  - ScottBurson 14y ago
    We can't easily know the state of the code, but we can easily read the number that you have assigned it. That number should reflect your own assessment of the code's stability. It's also a matter of how much cognitive load you want to impose on your users. We use dozens of different open-source packeages, each with its own version number. Can you really expect us to keep track of all of them? "Which Linux ZFS release was the first stable one?" "Uh, I think it was 0.6 something, or maybe 0.5.1?" Don't do that to your users. Call it 1.0.0.
    - j-kidd 14y ago
      > We can't easily know the state of the code, but we can easily read the number that you have assigned it. Exactly. To those who have been using 0.6.0_rc*, version 0.6.1 conveys the meaning "go ahead and upgrade, here's the stable release with no backward compatibility issue". You will get your version 1.0 after several pre-1.0 RC releases. That's the proper release management.
atyoung 14y ago
I've used both, and prefer btrfs in terms of implementation. For some reason the use maintenance and control feels more Linux to me. ZFS feels more Unix, which makes sense given the lineage. The raid arguments against btrfs are silly. Raid 5 is quite unnecessary, particularly with these kinds of file systems. I can only assume people making this argument have never maintained file systems of this type and clearly don't understand how to implement it correctly. Both ZFS and btrfs are the future though. If admins aren't seriously considering one of the two for thier server infrastructure then they probably shouldn't be admins.
cpeterso 14y ago
I misread this article title as meaning "ZFS has been backported to Linux 0.6.1". :)
jeffdavis 14y ago
Why is Oracle investing in Btrfs (GPL), rather than dual-licensing zfs as cddl/GPL?
- ianlevesque 14y ago
  They started it before they acquired Sun.
  - jeffdavis 14y ago
    Well, that kind of makes sense in a "we're incredibly lazy" way. But why not license ZFS as GPL, and see if that project makes better headway? No real cost there, except some possible confusion. Move the developers to whichever project seems to be winning.
reirob 14y ago
Here a study of the evoulution of Linux File Systems (post from 5 days ago): https://news.ycombinator.com/item?id=5431413 https://news.ycombinator.com/item?id=5431413 While it does NOT contain ZFS it is a great read.
glabifrons 14y ago
I think Oracle's decision to not keep Solaris open source, at least the ZFS portions, is enormously shortsighted. The fact that there is a ZFS implementation (with so many of the original ZFS engineers behind it) still being developed in the open and used by multiple operating systems, but especially the Linux juggernaut, shows that Oracle really doesn't have any benefit to keeping it closed any longer. It has forked. We now have the Oracle ZFS with features and functionality that is not in the open source variant, and the open source ZFS that is apparently adding features and commands that are not in the closed source ZFS. A huge selling point for the open source implementation is the fact that if you decide to change vendors or OSes, you can easily do so without having a huge data migration (zpool export on the old, zpool import on the new). Except, for Solaris 11+. You can't go back and forth between them, so once you're on Solaris 11, you're stuck. Yes, this is most definitely FUD, but I can easily see this being used in the not-so-distant future once Linux vendors start supporting/advertising it for themselves. I think that if Oracle were to open (and keep open) the newer releases (even if a few releases behind, like they were originally claiming they would), it would eliminate that argument completely. Personally, I'd be absolutely thrilled with a cross-platform on-disk ZFS (I triple-boot Linux/OSX/Solaris on my notebook). Professionally, I'd love to see a cross-platform on-disk ZFS simply to be able to throw the appropriate OS behind the data.
- drewcrawford 14y ago
  The big thing missing from the OSS implementations that Oracle 11 has got is FDE. It's possible with dmcrypt and LUKS, but you void most of the reasons for using ZFS. encryptFS is also a possibility, but it's both much less secure (an attacker can run ls) and also drops a few ZFS features like dedup. Meanwhile, Solaris 11 has FDE that actually works, and there seems to be no serious FOSS effort either to reverse engineer their work, or to design something better. In 2013, no software developer should be storing things without FDE unless they have unusual physical security measures. That makes FOSS ZFS a non-starter for most of the people who would use it.
  - glabifrons 14y ago
    Filesystem encryption is very handy for a notebook computer (I use it, myself), but in a datacenter it's value is a bit more questionable. Where do you store your encryption keys? If they're on a removable USB device (for example), you'd have to contact the datacenter personnel to plug them in in the event you had to reboot (which happens from time to time if you perform OS SRU uprades). If the USB device is left in the server and someone gains privileged access to the machine, they've got the key as well as the data. If the USB device is not in the server and someone gains privileged access to the machine, they still have access to the data. The only time disk encryption is valuable is when the machine is off or the disks are being transported.
groby_b 14y ago
What happened - did NetApp waive their patents? Am I missing something? Wasn't the consensus that ZFS is encumbered, and Oracle might or might not defend it, but who knows?
- takeda64 14y ago
  If I remember correctly, Sun responded with even more of their own patents at them and eventually they just settled.
ksec 14y ago
Lose Interest in ZFS when dev is pretty much stopped. I am looking forward to DragonFly HAMMER 2

209 points by iso8859-1 14y ago

So the two things I don't see are a comparison with BTRFS in terms of speed, and stability. I know ZFS is cool, but while we were waiting for it BTRFS got pretty darn good. I know ZFS has some additional features that BRTFS doesn't have, but If I have to use a unstable or slow filesystem to get those features when I could use by perfectly stable and fast filesystem while I wait for a few nice features I am going to say ZFS has missed its oppertuinity

wazoox 14y ago
People love to harp about the benefits and wonders of ZFS, but they often forgot to mention its limitations: most features have an impact on performance, memory consumption is ginormous, IO performance is generally not great (lower than with "simpler" FS), and managing your pools isn't that easy once you get serious about it.
- johnbellone 14y ago
  Not to mention the whole lack of an upstream. But all that aside ZFS was great when it was first introduced a few years back, especially with Sun backing OpenSolaris, but we've been jerked around for a few years. A ran a few ZFS pools on Linux a few builds ago and it was quite stable then. For something like a home storage system where I do not care about all the shortfalls vs. BTRFS I would reach to ZFS just because its what I know. For something that needs to be enterprise I'd hire someone that knows much more about it than me :).
  - dmpk2k 14y ago
    we've been jerked around for a few years Oracle's ZFS (and Solaris) fork is a deadish end. Most of the interesting action the past couple years has been happening among a collection of illumos (including critical ZFS members formerly from Sun), FreeBSD, OSX and even Linux hackers. I don't follow their activities closely, except to observe that they've been anything but idle. A lot of work has happened in the meantime, and continues. Hopefully one shows up to comment about it.
    - newman314 14y ago
      List of different versions of ZFS https://en.wikipedia.org/wiki/ZFS#Release_history https://en.wikipedia.org/wiki/ZFS#Release_history
    - natermer 14y ago
      Oracle's ZFS is now different then BSD/Linux ZFS. They have become incompatible file systems because Oracle has picked up their ball and taken it back home. For OSS ZFS the only upstream is 'collection of Illlumos'
    - johnbellone 14y ago
      I was running OpenIndiana for awhile at home before I just got tired of trying to hack together a bunch of patches. The problem with having a project that is pseudo OSS is that you can never actually use it seriously, its never reliable and for the most part its going to end in slow quiet death. In my opinion there are a were only a handful of reasons to use Solaris: Oracle, SPARC, ZFS and dtrace. The only reason to use it nowadays is because you can't scale x86 and need big iron for Oracle et al.
      - dmpk2k 14y ago
        Unrelated to the topic at hand, but I've been happy with SmartOS. It's firmly and solely an OSS server OS, it's easy to use, many of the uglier Solaris legacy bits have been sanded off, and it has a decent package system (pkgsrc). My earlier experiences with Solaris and OpenSolaris were mixed. SmartOS has been uniformly positive. Perhaps give it a try, although be aware that it (like everything illumos) is picky about the hardware.
- trotsky 14y ago
  Performance seems ok to me. 6x500gb 7.2k sata raid10 + 96gb ssd, 8gb ram. Run began: Fri Mar 29 08:32:24 2013 Include fsync in write timing Include close in write timing Command line used: iozone -ec -r 32 -s 16380m -l 2 -i 0 -i 1 -i 8 Throughput test with 2 processes Each process writes a 16773120 Kbyte file in 32 Kbyte records Parent sees throughput for 2 initial writers = 996073.19 KB/sec Avg throughput per process = 499898.70 KB/sec Parent sees throughput for 2 rewriters = 216128.36 KB/sec Avg throughput per process = 108075.14 KB/sec Parent sees throughput for 2 readers = 1232245.62 KB/sec Avg throughput per process = 616353.25 KB/sec Parent sees throughput for 2 re-readers = 1240045.15 KB/sec Avg throughput per process = 620251.62 KB/sec
  - dekhn 14y ago
    that's really not so impressive. you're just dumping extents down on an empty filesystem and re-reading them. you're really just measuring the fact that the FS isn't particularly getting in the way of using your hardware. Note also that rewriting drops to 108M/sec, which is pretty unimpressive.
    - trotsky 14y ago
      216M/sec - rewrite is suffering from a striding mismatch there with the COW, bs is 32k while stripe is 128k. Consumer uses 1M. I'm wondering which volume manager and fs under linux you'd expect better performance from in this configuration?
- craigyk 14y ago
  Yeah... what are you talking about? Enormous memory consumption = deduplication? Otherwise it doesn't seem enormous too me. Sure ZFS made a lot of departures from the standard toolset with all its own stuff... but that stuff is better once you learn it. I can easily get 600MB+/sec reads and writes on my pools with are pretty commodity stuff. One of my pools is 95% full, which is high, and I just tested it and got over ~100MB/sec write ~150MB read.... good enough for me. (Oh, and I just checked, it was scrubbing) Here are my little ZFS peeves: 1. you can't grow raidZ vdevs. Reduces flexibility. 2. I wish there was a version of scrub that rebalanced data across vdevs. By comparison BTRFS is nice, but nowhere close to ZFS. Last I saw a BTRFS scrub consists of cat'ing every file to null... which doesn't even cover the FS and metadata.
- glabifrons 14y ago
  "memory consumption is ginormous" Yes, it will use whatever memory you allow it to, but this is purely dynamic just as caching is in Linux. If you're not talking about the ARC, but about deduplication, of course it uses more memory - how would it not? "IO performance is generally not great (lower than with "simpler" FS)" This is sounding troll-ish, as that statement equates to: A filesystem that checksums all data and metadata and performs copy-on-write to protect the integrity of the on-disk state at all times is slower than a filesystem that does neither. Well, of course. But do those "simpler FS" have the ability to massively negate that effect by use of an SSD for the ZIL and L2ARC? There have been many articles showing higher throughput with large, slow 5400RPM drives combined with an SSD ZIL & L2ARC massively outperforming much faster enterprise drives. "managing your pools isn't that easy once you get serious about it" I'm fairly stunned by this statement, as I've yet to see an easier, more elegant solution for such a task. Before ZFS, I liked VXVM with VXFS, but I now consider it obsolete. Linux's LVM is downright painful in comparison. I've yet to play with btrfs, so I'll bite my tongue on what I've read so far on it. The deep integration of volume and pool management directly with the filesystem, essentially making them one and the same, is simply beautiful. Having these things separate (md, LVM, fs) after years of using ZFS seems so archaic and awkward to me. Disclosure: 100% of my ZFS experience has been on Solaris (10-11.1) and OpenSolaris/Nevada. I've not tried it on Linux, yet.
kev009 14y ago
Btrfs is actually a sordid state of affairs. It's been "two years out" for five years, which seems very disingenuous looking back. Groundbreaking FS development follows a pretty regular formula. 10 years seems to be the magic number. Major functionality (i.e RAID 5) is still just landing and has glaring issues. It's just now a couple years out. Meanwhile, ZFS has over 10 years of history, stably implements most of Btrfs _planned_ features, and has battle tested deployments. Granted, the SPL for Linux adds variables, but there are some big users of this particular project. So I approach Btrfs with the exact opposite mindset. It's guilty until innocent despite some FUD from the Linux camp early on that has settled down a bit since Oracle now has it's hands on both.
- simplexion 14y ago
  i.e. == that is. e.g. = example. RAID5 is not major functionality, it should no longer exist.
  - Dylan16807 14y ago
    Can you explain why you feel that way? ZFS has intelligently managed RAID that keeps the performance penalty minimal. I'd rather have multiple-redundancy parity than 2x mirroring, and it takes less space.
    - gtirloni 14y ago
      ZFS' raid-z is nothing but pain. Does it have standard raid-5 now?
      - simplexion 14y ago
        There is RAID-Z2 which allows for 2 discs to fail and RAID-Z3 which allows for 3. Problem is rebuild time is still slow. I wouldn't recommend to use RAID-Z1.
- dkhenry 14y ago
  This is why people think BTRFS isn't any good, because someone waltses up and says yeah well it doens't have XXX feature which only _one_ other filesystem has so its clearly lacking and immature. The truth it it works great its sufficently fast and has been stable for years. Yes it doesn't have Raid5 or Raid Z if you would like and I can't import and export pools the way I can in ZFS, but honestly if you jumping on a FS that has been marked stable for all of two days on Linux and your reasoning is you can't do software raid on the other one then best of luck to you.
antonios 14y ago
Let me understand: You claim that ZFS is the unstable or slow filesystem, and that BTRFS, which is not even yet marked as stable by its developers is the perfectly stable and fast one? That seems an opposite way of thinking.
- icebraining 14y ago
  Not ZFS, but ZFS for Linux.
brokenparser 14y ago
I tried resizing btrfs recently, my file came out truncated :(
__david__ 14y ago
> I know ZFS is cool, but while we were waiting for it BTRFS got pretty darn good. My own anecdotal evidence is that btrfs is not ready for prime time. I ran a couple btrfs file systems from kernel about 2.6.30 to 3.4 and finally determined that my system was so slow because of btrfs. I switched to xfs and an operation that used to take weeks (literally) now takes hours. Perhaps it's gotten significantly better in the last few revisions but I'd use caution if you want to use btrfs and still have good performance.
65a 14y ago
I'm getting +20k IOPs and nearly 1GB/sec read/write out of a mirror, something like 40K 1.5GB/sec out of a mirror+stripe on ZFS under FreeBSD. Disks are either 2x256GB SSD or 4x128GB SSD. Meanwhile BTRFS was so slow on random IO I had to toss it out in favor of the less reliable JFS or EXT4 on Gentoo. Don't use RAIDZ if you want performance with ZFS however, and you need to set it up twice before you get how to performance tune it.

silveira 14y ago

What about the license compatibility?

yankcrime 14y ago
First answer in the FAQ: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
mhurron 14y ago
It looks like very similar issues on the use end to the nvidia binary driver. Can't ship it in Linux but nothing (legally) prevents end users from incorporating it.
- lmickh 14y ago
  My concern with the license isn't legal so much as pain of administration. Maybe I'm just old fashion or lazy, but I prefer not to have to check my kernel repo against my kernel module repo to make sure they play nice. It is so much easier when you can just get it as part of the kernel. That is the reason why I avoid the Nvidia binary driver as well.
  - dpe82 14y ago
    If you're on Ubuntu, there's an apt package available in ZFS On Linux project's ppa. It downloads the source, builds it against your installed kernel and installs it. Rebuilds on any kernel update. Very handy. https://launchpad.net/~zfs-native/+archive/stable https://launchpad.net/~zfs-native/+archive/stable
merijnv 14y ago
The thing with both GPL and CDDL is that they both put restrictions on how you are allowed to distribute the program/source. i.e. you can't legally distribute code that has both GPL and CDDL parts. However, neither license puts restrictions on (end-user) use, which means that as long as you distribute the bits separately, running them together is perfectly fine. Which means (as their FAQ states) that while it can't ship as part of the kernel, there's no reason end-users wouldn't be allowed to load a separately distributed module into their kernel.

joosters 14y ago

Never mind all the promised wondrous features of ZFS, what are the recovery / fsck tools like? If the data recovery tools aren't mature, reliable and useful, then I'd advise anyone to stay away from a filesystem, no matter how world-ready the underlying FS code is. I'm probably biased; but I got screwed using ReiserFS. It was fast and great, but one day something went wrong and then I found that the reiserfsck program was practically useless. Very little work had been done on it, so any small inconsistencies in the FS meant your data was toast. Sure, keep backups and all that, but just be aware how important a good fsck tool is.

jiggy2011 14y ago
My understanding is that ZFS does a lot of healing itself on the fly. When you access a block, the block is checked against a checksum stored elsewhere on disk. If the block is bad, it is restored from a replica (so it's advisable to have 2 disks) while the original is healed. On writes ZFS also checks that each written block is valid before committing the new block to the filesystem. In the event of a bad write the new block is not committed and the old block remains, blocks are written originally to a separate area of the disk.
- joosters 14y ago
  Yes, and those are good features. But there's still plenty of room for errors. Bugs in the code, bad interactions with hardware, etc. Those are areas where ZFS is likely to be just as vulnerable as other file systems. More so, in fact, given the code size/complexity and its (relative) immaturity. I suspect (but I have no data!) that the majority of times that users have file system corruption and need to run fsck is due to bad software behaviour, and not failing disks.
  - jiggy2011 14y ago
    ZFS itself has been around for a while, was originally part of Solaris IIRC. It's using it on Linux that's new. If you have a bad software write, ZFS should be able to detect that in the same way it would a hardware error since the checksums won't match. Also worth noting that the checksums are themselves checksummed in a merkle tree. It also has a tool called "scrub" which can check data integrity without unmounting the disk. Of course if your filesystem has buggy code for checksumming/repair then you are boned whatever.

runako 14y ago

If it's ready for wide scale deployment, I wonder why the team decided against signaling that by calling it 1.0 instead of 0.6.1. A version number < 1 makes me think the developers still think it's pre-release quality. That may not be the case here, but it makes me wonder.

aneth4 14y ago
My thoughts exactly. If you're going to declare something production ready, but don't have the nuts to call it 1.0, I don't believe you. Maybe 0.6.1 just has a nice ring that 1.0 doesn't quite get.
prakahsurya 14y ago
No, I can assure you we definitely do not think it's "pre-release" quality. I work closely with Brian Behlendorf, and I'm sure he would not have made the stable release if he thought it wasn't ready for prime time. It's a little disheartening to see people pay so much attention to a fictitious number, which really has no regard to the actual state of the code/project. Whether v1.0 or v0.1 was used, the quality of the release would not differ any.
- ScottBurson 14y ago
  We can't easily know the state of the code, but we can easily read the number that you have assigned it. That number should reflect your own assessment of the code's stability. It's also a matter of how much cognitive load you want to impose on your users. We use dozens of different open-source packeages, each with its own version number. Can you really expect us to keep track of all of them? "Which Linux ZFS release was the first stable one?" "Uh, I think it was 0.6 something, or maybe 0.5.1?" Don't do that to your users. Call it 1.0.0.
  - j-kidd 14y ago
    > We can't easily know the state of the code, but we can easily read the number that you have assigned it. Exactly. To those who have been using 0.6.0_rc*, version 0.6.1 conveys the meaning "go ahead and upgrade, here's the stable release with no backward compatibility issue". You will get your version 1.0 after several pre-1.0 RC releases. That's the proper release management.

atyoung 14y ago

I've used both, and prefer btrfs in terms of implementation. For some reason the use maintenance and control feels more Linux to me. ZFS feels more Unix, which makes sense given the lineage. The raid arguments against btrfs are silly. Raid 5 is quite unnecessary, particularly with these kinds of file systems. I can only assume people making this argument have never maintained file systems of this type and clearly don't understand how to implement it correctly. Both ZFS and btrfs are the future though. If admins aren't seriously considering one of the two for thier server infrastructure then they probably shouldn't be admins.

cpeterso 14y ago

I misread this article title as meaning "ZFS has been backported to Linux 0.6.1". :)

jeffdavis 14y ago

Why is Oracle investing in Btrfs (GPL), rather than dual-licensing zfs as cddl/GPL?

ianlevesque 14y ago
They started it before they acquired Sun.
- jeffdavis 14y ago
  Well, that kind of makes sense in a "we're incredibly lazy" way. But why not license ZFS as GPL, and see if that project makes better headway? No real cost there, except some possible confusion. Move the developers to whichever project seems to be winning.

reirob 14y ago

Here a study of the evoulution of Linux File Systems (post from 5 days ago): https://news.ycombinator.com/item?id=5431413 https://news.ycombinator.com/item?id=5431413 While it does NOT contain ZFS it is a great read.

glabifrons 14y ago

I think Oracle's decision to not keep Solaris open source, at least the ZFS portions, is enormously shortsighted. The fact that there is a ZFS implementation (with so many of the original ZFS engineers behind it) still being developed in the open and used by multiple operating systems, but especially the Linux juggernaut, shows that Oracle really doesn't have any benefit to keeping it closed any longer. It has forked. We now have the Oracle ZFS with features and functionality that is not in the open source variant, and the open source ZFS that is apparently adding features and commands that are not in the closed source ZFS. A huge selling point for the open source implementation is the fact that if you decide to change vendors or OSes, you can easily do so without having a huge data migration (zpool export on the old, zpool import on the new). Except, for Solaris 11+. You can't go back and forth between them, so once you're on Solaris 11, you're stuck. Yes, this is most definitely FUD, but I can easily see this being used in the not-so-distant future once Linux vendors start supporting/advertising it for themselves. I think that if Oracle were to open (and keep open) the newer releases (even if a few releases behind, like they were originally claiming they would), it would eliminate that argument completely. Personally, I'd be absolutely thrilled with a cross-platform on-disk ZFS (I triple-boot Linux/OSX/Solaris on my notebook). Professionally, I'd love to see a cross-platform on-disk ZFS simply to be able to throw the appropriate OS behind the data.

drewcrawford 14y ago
The big thing missing from the OSS implementations that Oracle 11 has got is FDE. It's possible with dmcrypt and LUKS, but you void most of the reasons for using ZFS. encryptFS is also a possibility, but it's both much less secure (an attacker can run ls) and also drops a few ZFS features like dedup. Meanwhile, Solaris 11 has FDE that actually works, and there seems to be no serious FOSS effort either to reverse engineer their work, or to design something better. In 2013, no software developer should be storing things without FDE unless they have unusual physical security measures. That makes FOSS ZFS a non-starter for most of the people who would use it.
- glabifrons 14y ago
  Filesystem encryption is very handy for a notebook computer (I use it, myself), but in a datacenter it's value is a bit more questionable. Where do you store your encryption keys? If they're on a removable USB device (for example), you'd have to contact the datacenter personnel to plug them in in the event you had to reboot (which happens from time to time if you perform OS SRU uprades). If the USB device is left in the server and someone gains privileged access to the machine, they've got the key as well as the data. If the USB device is not in the server and someone gains privileged access to the machine, they still have access to the data. The only time disk encryption is valuable is when the machine is off or the disks are being transported.

groby_b 14y ago

What happened - did NetApp waive their patents? Am I missing something? Wasn't the consensus that ZFS is encumbered, and Oracle might or might not defend it, but who knows?

takeda64 14y ago
If I remember correctly, Sun responded with even more of their own patents at them and eventually they just settled.

ksec 14y ago

Lose Interest in ZFS when dev is pretty much stopped. I am looking forward to DragonFly HAMMER 2