
OpenZFS on OS X - blacktulip
http://openzfsonosx.org/
======
js2
This is the Mac flavor of [http://open-zfs.org/wiki/Main_Page](http://open-
zfs.org/wiki/Main_Page) which is aiming to share development among the various
OS specific ZFS implementations. So it's an early successor to MacZFS -
[https://code.google.com/p/maczfs/wiki/DevelopmentOverview](https://code.google.com/p/maczfs/wiki/DevelopmentOverview)

------
aroch
This appears to be a rebrand of MacZFS, which was never as performant as
ZEVO[1] in my usage

1:
[http://getgreenbytes.com/solutions/zevo/](http://getgreenbytes.com/solutions/zevo/)

~~~
dewey
"Please note that if you are running MacZFS, you should use their site
instead: maczfs.org"

Sounds like a different project. That's just from giving it a quick glance. No
idea what's going on under the hood.

Edit: As the next comment points out, I'm wrong on that one.

~~~
aroch
Take a gander at their github: [https://github.com/zfs-
osx](https://github.com/zfs-osx)

    
    
         OpenZFS for Apple OS X
    
        http://MacZFS.org/
        maczfs-devel@googlegroups.co

~~~
masklinn
More to the point,

> This is a very early alpha of ZFS on OSX, to be the next generation of
> MacZFS.

from the project's readme.

~~~
aroch
That's nice, its still a rebrand of MacZFS and is still missing some key
features (like TRIM).

~~~
craigyk
I thought with newer SSDs TRIM is no longer as important and in some FSs even
has drawbacks?

~~~
aroch
Some SSDs implement TRIM at the firmware level, but Trim support in the fs is
pretty much required if you want to use ZFS on an SSD

~~~
wtallis
WTF are you talking about? TRIM refers to only one thing: the ATA TRIM command
that gets sent to the drive by the OS. TRIM isn't the same as garbage
collection or wear levelling, though it makes it easier for the SSD to do
both. It is however completely unnecessary for the drive and filesystem to
work together to correctly store data. It's just a performance hint, and one
that isn't even that important for many drives and workloads.

------
openzfsonosx
The project's GitHub Repository is
[https://github.com/openzfsonosx](https://github.com/openzfsonosx).
Technically, OpenZFS on OS X is a port of ZFS on Linux, which at the moment we
use as the direct upstream git repository. In turn, ZFS on Linux uses illumos
as its upstream. However, significant elements of OpenZFS on OS X are ported
directly from illumos and from FreeBSD, which, like ZFS on Linux, uses illumos
as upstream. OpenZFS on OS X is in no way a "rebrand" of MacZFS, which has a
completely different, and rather old, codebase and had a completely different
set of contributors.

------
mistertrotsky
Congratulations on the site launch! I've been using trunk builds in production
for the last three months. Very few issues for pre-alpha software.

------
zastavka
Looks interesting, but from what I understand it's a really really bad idea to
run ZFS without ECC RAM. So is this geared purely toward Mac Pro/Hackintosh
users, since no other Mac models use ECC RAM? Or does this somehow do things
differently?

Oh, and it looks like it still doesn't play nice with Spotlight. That's a
dealbreaker for me until they fix that.

~~~
wtallis
I've seen a lot of people repeat that assertion about using ECC RAM with ZFS,
but I've never seen it explained in detail. Is ZFS actually more susceptible
to data loss if RAM gets corrupted as compared with other file systems, or is
it just an overblown piece of advice about not forgetting your RAM when trying
to make a backup system reliable?

~~~
tachion
This is overblown at all, ZFS needs ECC as it doesnt detect memory corruption
on its own, and here's some explenation:
[http://forums.freenas.org/index.php?threads/ecc-vs-non-
ecc-r...](http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-
zfs.15449/)

~~~
stormbrew
I think the question is, all else equal, is ZFS _less_ reliable than
alternative filesystems/software-RAID on non-ECC?

~~~
Amezarak
Read the linked FreeNAS forum thread. The answer is yes.

On a non-ZFS file system, a bit getting flipped in memory will result in the
file being written incorrectly. That sucks. You can read the file ten times
and nothing more will happen. Your file is corrupted, maybe even unreadable.
If you were really unlucky, maybe some file system metadata was corrupted.

On ZFS, the same single bit being flipped can result in ZFS writing _more_ bad
data when the file is read, because ZFS will try to fix the file but can never
do it successfully since the memory is bad (and the original checksum was
wrong). Hypothetically that could keep happening forever, trashing more and
more bits, all because of ZFS.

Now, the real question is how often that scenario can arise and does that
justify the cost of ECC RAM in your mind.

~~~
craigyk
So you're saying if you aren't using RAID on your ZFS vdevs than ZFS with non-
ECC is no worse than anything else... and there is a valid scenario for doing
so. I use ZFS on offline backup drives so that I can periodically mount them
and scrub them too see if they need to be replaced updated. In my mind this is
faster and more reliable than any custom verification scheme I might have come
up with.

Also, if I understand correctly, your disaster scenario requires the RAM to
keep repeatedly fing up in a way that allows ZFS to screw up repeatedly during
corrections but coincidentally won't cause the system to outright crash? It's
possible, but in my experience most of the ECC errors I've seen are pretty
transient.

------
dmilith
MacZFS != OpenZFS on OSX project. It's successor of MacZFS. MacZFS was
abandoned a while ago.

------
SmileyKeith
This post seems to have destroyed the site. Excited to try it out though.

