On 01/22/2013 03:56 AM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: >> From: Sašo Kiselkov [mailto:skiselkov...@gmail.com] >> >> as far as incompatibility among products, I've yet to come >> across it > > I was talking about ... install solaris 11, and it's using a new version > of zfs that's incompatible with anything else out there. And vice-versa.
Wait, you're complaining about a closed-source vendor who did a conscious effort to fuck the rest of the community over? I think you're crying on the wrong shoulder - it wasn't the open ZFS community that pulled this dick move. Yes, you can argue that the customer isn't interested in politics, but unfortunately, there are some things that we simply can't do anything about - the ball is in Oracle's court on this one. > (Not sure if feature flags is the default, or zpool 28 is the default, > in various illumos-based distributions. But my understanding is that > once you upgrade to feature flags, you can't go back to 28. Which means, > mutually, anything >28 is incompatible with each other.) You have to > typically make a conscious decision and plan ahead, and intentionally go > to zpool 28 and no higher, if you want compatibility between systems. Yes, feature flags is the default, simply because it is a way for open ZFS vendors to interoperate. Oracle is an important player in ZFS for sure, but we can't let their unwillingness to cooperate with others hold the whole community in stasis - that is actually what they would have wanted. >> Let us know at z...@lists.illumos.org how that goes, perhaps write a blog >> post about your observations. I'm sure the BTRFS folks came up with some >> neat ideas which we might learn from. > > Actually - I've written about it before (but it'll be difficult to find, > and nothing earth shattering, so not worth the search.) I don't think > there's anything that zfs developers don't already know. Basic stuff like > fsck, and ability to shrink and remove devices, those are the things btrfs > has and zfs doesn't. (But there's lots more stuff that zfs has and btrfs > doesn't. Just making sure my previous comment isn't seen as a criticism > of zfs, or a judgement in favor of btrfs.) Well, I learned of the LZ4 compression algorithm in a benchmark comparison of ZFS, BTRFS and other filesystem compression. Seeing that there were better things out there I decided to try and push the state of ZFS compression ahead a little. > And even with a new evaluation, the conclusion can't be completely clear, > nor immediate. Last evaluation started about 10 months ago, and we kept > it in production for several weeks or a couple of months, because it > appeared to be doing everything well. (Except for features that were known > to be not-yet implemented, such as read-only snapshots (aka quotas) and > btrfs-equivalent of "zfs send.") Problem was, the system was unstable, > crashing about once a week. No clues why. We tried all sorts of things > in kernel, hardware, drivers, with and without support, to diagnose and > capture the cause of the crashes. Then one day, I took a blind stab in the > dark (for the ninetieth time) and I reformatted the storage volume ext4 > instead of btrfs. After that, no more crashes. That was approx 8 months ago. Even negative results are results. I'm sure the BTRFS devs would be interested in your crash dumps. Not saying that you are in any way obligated to provide them - just pointing out that perhaps you were hitting some snag that could have been resolved (or not). > I think the only thing I could learn upon a new evaluation is: #1 I hear > "btrfs send" is implemented now. I'd like to see it with my own eyes before > I believe it. #2 I hear quotas (read-only snapshots) are implemented now. > Again, I'd like to see it before I believe it. #3 Proven stability. Never > seen it yet with btrfs. Want to see it with my eyes and stand the test of > time before it earns my trust. Do not underestimate these guys. They could have come up with a cool new feature that we haven't heard about anything at all. One of the things knocking around in my head ever since it was mentioned a while back on these mailing lists was a metadata-caching device, i.e. a small yet super-fast small device that would allow you to just store the pool topology for very fast scrub/resilver. These are the sort of things that I meant - they could have thought about filesystems in ways that haven't been done widely before. While BTRFS may be developmentally behind ZFS, one still has to have great respect for the intellect of its developers - these guys are not dumb. Cheers, -- Saso _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
