

ZFS on Linux 0.6.1 released: Ready for wide scale deployment - iso8859-1
https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups#!topic/zfs-announce/ZXADhyOwFfA

======
dkhenry
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

~~~
kev009
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.

~~~
mattbee
We have deployed ZFS for the last few years on some large backup servers
(Solaris and FreeBSD) and our experience has been pretty rotten - the command
line is slow at managing a few hundred volumes, it becomes unusable during a
rebuild, and it has / had a rotten bug where if you fill a volume up to 100%,
you need to allocate more space before you can delete it.

It's been a multi-year mistake for us and we're busy changing these servers
back to nice simple XFS volumes.

~~~
smegel
And if you use more than 80% space performance degrades like a dog. We still
use XFS for really large volumes though and it has always been fast and never
missed a beat.

------
glabifrons
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
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
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.

~~~
drewcrawford
> The only time disk encryption is valuable is when the machine is off or the
> disks are being transported.

I'm thinking about the case where you have a computer in the home or office
environment, e.g. the burglary attack vector. It's not just notebooks that get
stolen.

I'm also considering the corporate or government espionage vector, where you
have a reasonably skilled on-site attacker trying to read or modify the disk
contents. In this case you are typing the keys in on boot, and you either
ignore the RAM extraction attacks (which are difficult to execute in practice
for non-academic attackers) or you can mitigate them by storing in L1 cache
and so on.

Datacenters have unusually high physical security, and in addition I don't
generally store highly sensitive data there (my work doesn't involve PCI
compliance etc.) Whereas I do have PCI-level data about myself on my own
computers.

~~~
glabifrons
"It's not just notebooks that get stolen."

Very good point. I guess I've been working in environments with datacenters
too long. :)

"I'm also considering the corporate or government espionage vector, where you
have a reasonably skilled on-site attacker trying to read or modify the disk
contents."

Again though, that only protects you if the disks are out or the machine is
down. If you have someone with that level of skill within your organization,
they'll likely gain access to the running computer where the data has already
been made accessible in decrypted form.

------
runako
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.

~~~
prakahsurya
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
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
> 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.

------
joosters
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.

~~~
wereHamster
There is no fsck for ZFS. Because the ZFS developers at Sun/Oracle believe
that ZFS is robust enough to never corrupt (untrue) and in case it does you
should have a backup.

I got screwed by ZFS, and I was able to recover the filesystem by learning its
on-disk structure and fixing it directly on-disk. Something that a decent fsck
tool could do. But no, ZFS never breaks. Go figure.

~~~
dmpk2k
My employer has thousands of large machines with ZFS on them. We've seen
corruption happen once, five years ago.

Maybe we've just been really lucky.

~~~
onemorepassword
The idea that you can have corruption and nothing to fix it with already
sounds scary enough to me.

Especially for those of us that _don't_ have thousands of machines and can
therefor be badly screwed by one issue.

~~~
dmpk2k
Given the way ZFS works, you'll have to elaborate on what an fsck would do
that ZFS doesn't automatically do already.

What I find scary is silently corrupt data, something which is a problem for
most other filesystems. I've seen ZFS catch and fix that error orders of
magnitude more often than I've seen ZFS flake out. If we're talking risk
analysis, I feel you're worried about a mouse in the corner, while a starved
tiger is hungrily licking its chops while staring at you.

~~~
wereHamster
I think it's unfortunate that Sun called it 'scrub' instead of 'fsck'. Because
the two are largely equivalent in functionality (to the extents supported by
the filesystem). Both fix filesystem corruption if they can. Just scrub can be
run while the filesystem is mounted, whereas the traditional fsck must be run
when the filesystem is offline.

However, scrub does not make ZFS perfect. There are still ways the filesystem
can become corrupted without scrub noticing. Or corrupted in a way so that ZFS
fails to recover from, even though recovering would be dead simple.

The attitude of the ZFS developers only works in the enterprise market: Your
data is safe (checksummed, scrubbed, replicated using RAID-Z), but if a bit
flips in the superblock just restore from your backup, because we won't
provide tools to recover from that.

~~~
dmpk2k
While I concur with most of your points, I must point out that there are four
uberblocks, not one; a flipped bit will not impair the pool.

Let's argue that bits flip in all four uberblocks though, then ZFS will use
the previous valid commit, which also has four uberblocks (ZFS is a CoW FS).
And so on backwards for quite a few transactions. All these uberblocks are
spread out at the beginning and end of each disk.

ZFS has a policy that the more important the data (and the top of the tree is
most important), the more copies there are, although a user can also define
how many duplicates there should be at the leaves of the tree.

Basically, you'd need a _very_ trashed disk to render an entire pool dead.
You're not going to recover from that, regardless of filesystem.

~~~
wereHamster
Well, ZFS clearly didn't use the extra copies, nor did it try to use the
previous uberbocks. Otherwise it would've been able to mount the filesystem,
don't you think? And I disagree that the disk was very trashed, if all it took
was to invalidate a few uburblocks to get the filesystem mounted again.

~~~
dmpk2k
Did you use zpool import -F (are you sure)? I'm surprised that'd be necessary
though, given my experiences. How long ago was this?

------
atyoung
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.

------
reirob
Here a study of the evoulution of Linux File Systems (post from 5 days ago):
<https://news.ycombinator.com/item?id=5431413>

While it does NOT contain ZFS it is a great read.

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

~~~
ianlevesque
They started it before they acquired Sun.

~~~
jeffdavis
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.

------
silveira
What about the license compatibility?

~~~
mhurron
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
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
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>

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

------
groby_b
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
If I remember correctly, Sun responded with even more of their own patents at
them and eventually they just settled.

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

