On Sat, 7 Sept 2024 at 04:12, Gea <g...@napp-it.org> wrote:
> Illumos ZFS has not seen as many problems up to dataloss in 10 years as
> one or the other Linux ZFS distribution in the last year.
Right, and this is the most critical metric for us. Any increase in
data loss is unacceptable.
> is how to take over code from a stable branch ex 2.2.6 or better a
> former with a better stability like 2.2.3 or what TrueNAS is using as
> stable branch.
It's worrying to me that you're able to characterise 2.2.3 as having
"better stability" than 2.2.6! Why is that? Surely each micro
release should work better than the previous one in a particular
train.
> The real question from a user view is how to preserve compatibility with
> a ZFS pool from a current BSD, Debian, Ubuntu or TrueNAS and when to get
> important Open-ZFS features like ZSTD, Draid, Raid-Z exansion, Fast
> Dedup, direct io or higher limits ex on recsize and much more to come
> while value stability as item2. Stability and compatibility are not
> either or. Find a way to get newer Open-ZFS features including bugfix
> commits with the best achievable stability. Not to have newer ZFS
> features is not an option. Have your cake and eat it.
To crib from Wikipedia:
| The proverb literally means "you cannot simultaneously
| retain possession of a cake and eat it, too". Once the
| cake is eaten, it is gone. It can be used to say that
| one cannot have two incompatible things, or that one
| should not try to have more than is reasonable.
https://en.wikipedia.org/wiki/You_can%27t_have_your_cake_and_eat_it
I am very much in favour of having new features and bug fixes imported
from OpenZFS, and we do import them over time. It's important for a
project to have a strong sense of what it values, which often means
prioritising those values when making decisions. For us, the
hierarchy has to be something like this:
1. not shipping regressions, not creating data loss
2. importing bug fixes
3. importing new features and performance improvements
It's something of an aphorism in software engineering at this point,
but we're essentially trading between constraints. If we assume that
we can't magically produce extra contributors willing to work on this
(i.e., cost/staffing is fixed) then we're trading off between:
- scope of features (e.g., compatibility with OpenZFS 2.2.6)
- quality of implementation (e.g., no regressions or data loss!)
- when the work is likely to be completed
We are unwilling to sacrifice quality, which means we can only pick
one other constraint in this triangle. If the goal is more features,
then it will, as you're noticing, take longer to get done.
> Maybe a staging model can be one solution like an older more stable
> Open-ZFS branch > Illumos testing > Illumos stable (similar to what
> current Illumos is), just like we see it in Open-ZFS or the OmniOS
> approach or in the Open-ZFS world with Open-ZFS forks on OSX or Windows.
> This would allow newest Open-ZFS features to appear with a delay but to
> appear for sure. Maybe newer long awaited bits like the recent NFS and
> SMB improvements have also a chance to appear in a Illumos testing
> branch for wider testings.
There are several challenges with a testing/unstable branch approach
in general; e.g.,
- Who is going to maintain the testing/unstable branch?
- What are the rules around integration of changes into the
testing branch? Obviously there must be fewer rules and
lower standards, otherwise you'd just go straight to the
master branch.
- Who will be running the testing/unstable day-to-day on
their computers instead of master?
- What is the process for promoting changes from the
testing/unstable branch to master? Ultimately this
question is: who is going to do the work (that is already
not being done today) to get those changes into the master
branch?
If you're saying that you're stepping up and are going to work on
porting a current OpenZFS release branch back to illumos, that's
certainly exciting news! I think it would be worth drafting an IPD
with your plans to get started, which we can review and help with!
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/T627f77e1b29a7b53-M30c4c4717dd8e3ba6ee9c265
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
