While not a blocker it's also likely the ability to force export a suspended pool will also be ready in time (PR 11082). This has been mentioned elsewhere, but to aid in your planning we're currently pushing to get the direct IO functionality wrapped up (PR 10018) for inclusion in 2.1. If for no other reason than to avoid an entire type of OpenZFS pool which can't be imported with the default Debian packages.
#DEBIAN OPENZFS 2.0 PATCH#
#DEBIAN OPENZFS 2.0 PLUS#
It will include dRAID (which has already been merged) plus any other changes which have been finalized and integrated before cutting the 2.1 branch from the master branch. We will continue to apply patches as needed to this release even after OpenZFS 2.1 has been tagged.Ģ.1 - Minor release, targeted for early 2021. I'd encourage downstream distributions and users to adopt this release if possible since it will be easiest for us to support long term. It will also provide a stable user space library API (libzfs, libzfs_core). Users running kernels newer than 5.9 will need to migrate to the 2.0 release due to the difficulty in backporting the required patches.Ģ.0 - The 2.0 branch will get documentation updates, important bug fixes, minor performance improvements, and any required kernel compatibility changes. If Debian's policy is to only apply what you need it should be straight forward to just cherry pick those changes and skip the kernel compatibility patches if they're not needed.Ġ.8 - The 0.8 branch is now 18 months old and will only receive important bug fixes and minimal kernel compatibility changes. However, since the kernel is a moving target I expected we will have to pull in some larger changes as needed to maintain compatibility over the lifetime of the 2.0 branch. This is something we will do our best to avoid with the 2.0 branch.
#DEBIAN OPENZFS 2.0 SERIES#
I know this hasn't been crystal clear in the past, and I agree the 0.8 series underwent more churn that I would have liked. Let me do my best to summarize the plan for the release branches to help you decide.
I'm not sure if this is more suited for the mailing list-I can move the discussion there if that's more appropriate.
Which portion of the codebase does your question involve? The question here is restricted entirely to old-school, pure-stable, users who are concerned about stability over features, at all costs. (Though, notice that Ubuntu LTS shipped with 0.8.3, so that may be happening for years to come anyway).Īs a note to any Debian user reading this who wants to say "please choose 2.0, because I want some new feature X": please don't worry about that, there will most definitely be ZFS 2.0, readily accessible in backports. Moreover, I would prefer to not have Debian users showing up here, asking for support for an "outdated" version, taxing upstream developer's time. Conversely, the 0.8-branch might simply receive no more attention at all-and there are already many changes relative to that branch that prevent git cherry-pick from applying cleanly. The 0.8-branch picked up some significant features throughout its lifetime, so there's a concern that an early 2.0 or perhaps 2.0.1 might be left in the past, with bug fixes that may need significant back-porting to apply to such an old release (and I'm thinking far down the line, say at least 3 years). It's (perhaps oddly) not Debian policy to import new point releases, but rather cherry-pick these targeted fixes. What are the plans to provide noninvasive, targeted bug fixes for each of these branches?įrom the perspective of downstream Debian, we'd like to only be including the least dangerous possible fixes-this means avoiding things like any new features and even future kernel compatibility (since we aren't upgrading the kernel either).In my opinion, there is really one point that is of primary concern for Debian stable. Downstream in Debian, we're trying to decide if Debian 11 should ship with the ZFS 2.0-branch or the 0.8-branch.
0 kommentar(er)
