4 ms·

I can't say about the specific version, but ZFS has a history of great stability, with very few isolated cases of data loss. 0.8 also has trim support :-)

paulmd 7y ago
ZFS on BSD has that track record. ZFS on Linux already has had a couple incidents in a relatively short track record. The incident where updating your Ubuntu kernel resulted in data loss probably could not have occurred under the BSD model due to close coupling between the kernel and the filesystem.
- rincebrain 7y ago
  To be fair to ZoL, at least the nastiest data loss bug I can think of (hole_birth) was cross-platform, so FBSD, ZoL, illumos, and everyone else in the OpenZFS family was equally affected.
  - paulmd 7y ago
    I was thinking of this one. https://news.ycombinator.com/item?id=16797919 https://news.ycombinator.com/item?id=16797919 The whole downstream/upstream model with different parts of the OS kernel / filesystem / userland moving out of sync with each other through multiple levels of backporting is not a positive one for reliability. FreeBSD is FreeBSD and the buck stops there. Responsibility is too diffuse in the Linux model to get the kind of reliability that FreeBSD has enjoyed. I realize that I'm being a bit of a fuddy-duddy but it really didn't take too long at all for the ZoL team to start making dumb mistakes that cause data loss. Hopefully it's a learning experience and didn't happen again. I myself have a dataset that I can't send from a FreeBSD system to my Ubuntu 16.04/ZoL backup server. It worked at one point, as of about a year ago it no longer does. When the send is finished, the client machine just spins forever. I've tried everything short of formatting and reinstalling the backup server. I tried incremental sends, I tried re-sending the whole thing, I tried killing the pool, updating everything and re-creating the pool, I tried messing with microcode in case it was a wayward regression from Spectre, etc etc. ZoL just won't receive that dataset anymore. Best of luck to the ZoL guys but I guess FreeBSD is working well enough as a data storage layer for me. Too much weird shit going on with ZoL.
    - rincebrain 7y ago
      Ah yes, the zap shrinking bug, that was silly, but as the one I mentioned illustrates, not all of them (or even necessarily most of them, few though there have been) originate with ZoL. Have you tried reporting the bug you're having with send/recv? I imagine people would care about that kind of reproducible failure. Re: FBSD versus ZoL, go with what works for you. If something is working well enough, I'm not going to advocate changing it. (This tends to be an unpopular opinion among other people though.)

paulmd 7y ago

ZFS on BSD has that track record. ZFS on Linux already has had a couple incidents in a relatively short track record. The incident where updating your Ubuntu kernel resulted in data loss probably could not have occurred under the BSD model due to close coupling between the kernel and the filesystem.

rincebrain 7y ago
To be fair to ZoL, at least the nastiest data loss bug I can think of (hole_birth) was cross-platform, so FBSD, ZoL, illumos, and everyone else in the OpenZFS family was equally affected.
- paulmd 7y ago
  I was thinking of this one. https://news.ycombinator.com/item?id=16797919 https://news.ycombinator.com/item?id=16797919 The whole downstream/upstream model with different parts of the OS kernel / filesystem / userland moving out of sync with each other through multiple levels of backporting is not a positive one for reliability. FreeBSD is FreeBSD and the buck stops there. Responsibility is too diffuse in the Linux model to get the kind of reliability that FreeBSD has enjoyed. I realize that I'm being a bit of a fuddy-duddy but it really didn't take too long at all for the ZoL team to start making dumb mistakes that cause data loss. Hopefully it's a learning experience and didn't happen again. I myself have a dataset that I can't send from a FreeBSD system to my Ubuntu 16.04/ZoL backup server. It worked at one point, as of about a year ago it no longer does. When the send is finished, the client machine just spins forever. I've tried everything short of formatting and reinstalling the backup server. I tried incremental sends, I tried re-sending the whole thing, I tried killing the pool, updating everything and re-creating the pool, I tried messing with microcode in case it was a wayward regression from Spectre, etc etc. ZoL just won't receive that dataset anymore. Best of luck to the ZoL guys but I guess FreeBSD is working well enough as a data storage layer for me. Too much weird shit going on with ZoL.
  - rincebrain 7y ago
    Ah yes, the zap shrinking bug, that was silly, but as the one I mentioned illustrates, not all of them (or even necessarily most of them, few though there have been) originate with ZoL. Have you tried reporting the bug you're having with send/recv? I imagine people would care about that kind of reproducible failure. Re: FBSD versus ZoL, go with what works for you. If something is working well enough, I'm not going to advocate changing it. (This tends to be an unpopular opinion among other people though.)