7 ms·

OpenZFS on OS X

83 points by blacktulip 13y ago

zastavka 13y ago
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 13y ago
  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 13y ago
    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-ram-and-zfs.15449/ http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-r...
    - stormbrew 13y ago
      I think the question is, all else equal, is ZFS less reliable than alternative filesystems/software-RAID on non-ECC?
      - craigyk 13y ago
        I think the answer is No. ZFS users are just extra paranoid and looking for the next SPOF.
      - Amezarak 13y ago
        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 13y ago
        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.
        wtallis 13y ago
        > 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) It sounds like this applies to a stuck bit of memory, not just a once-off corruption. If so, then you're still not making a fair comparison - if your memory is broken, then any filesystem will continue to write bad data when flushing cache residing on that broken chip, and if the broken piece of memory is used to store more critical data structures then the potential damage is unbounded. But this is orders of magnitude less common than the transient memory errors that are the actual reason for having ECC. So once again, assuming the only reasonable scenario of a bit being randomly corrupted in a fully-functional memory module, how much more fragile is ZFS than other modern file systems? Do other filesystems re-read and re-parse their on-disk data structures more often where ZFS caches them in memory? If ZFS writes a corrupted block to disk with a non-matching checksum (or a correct block with corrupted checksum), is that corruption contagious and capable of spreading to other blocks or other files as a result of trying to read the corrupted block back from the disk?
aroch 13y ago
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 13y ago
  "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 13y ago
    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 13y ago
      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 13y ago
        That's nice, its still a rebrand of MacZFS and is still missing some key features (like TRIM).
        craigyk 13y ago
        I thought with newer SSDs TRIM is no longer as important and in some FSs even has drawbacks?
        aroch 13y ago
        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
mistertrotsky 13y ago
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.
SmileyKeith 13y ago
This post seems to have destroyed the site. Excited to try it out though.
js2 13y ago
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
dmilith 13y ago
MacZFS != OpenZFS on OSX project. It's successor of MacZFS. MacZFS was abandoned a while ago.
openzfsonosx 13y ago
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.

83 points by blacktulip 13y ago

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 13y ago
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 13y ago
  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-ram-and-zfs.15449/ http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-r...
  - stormbrew 13y ago
    I think the question is, all else equal, is ZFS less reliable than alternative filesystems/software-RAID on non-ECC?
    - craigyk 13y ago
      I think the answer is No. ZFS users are just extra paranoid and looking for the next SPOF.
    - Amezarak 13y ago
      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 13y ago
        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.
      - wtallis 13y ago
        > 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) It sounds like this applies to a stuck bit of memory, not just a once-off corruption. If so, then you're still not making a fair comparison - if your memory is broken, then any filesystem will continue to write bad data when flushing cache residing on that broken chip, and if the broken piece of memory is used to store more critical data structures then the potential damage is unbounded. But this is orders of magnitude less common than the transient memory errors that are the actual reason for having ECC. So once again, assuming the only reasonable scenario of a bit being randomly corrupted in a fully-functional memory module, how much more fragile is ZFS than other modern file systems? Do other filesystems re-read and re-parse their on-disk data structures more often where ZFS caches them in memory? If ZFS writes a corrupted block to disk with a non-matching checksum (or a correct block with corrupted checksum), is that corruption contagious and capable of spreading to other blocks or other files as a result of trying to read the corrupted block back from the disk?

aroch 13y ago

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 13y ago
"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 13y ago
  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 13y ago
    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 13y ago
      That's nice, its still a rebrand of MacZFS and is still missing some key features (like TRIM).
      - craigyk 13y ago
        I thought with newer SSDs TRIM is no longer as important and in some FSs even has drawbacks?
        aroch 13y ago
        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

mistertrotsky 13y ago

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.

SmileyKeith 13y ago

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

js2 13y ago

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

dmilith 13y ago

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

openzfsonosx 13y ago

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.