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

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

zfs-discuss mailing list

Reply via email to