Describe in the OpenZFS documentation all known data corruption bugs and all other critical bugs and affected OpenZFS versions

[makhomed]

Describe the feature would like to see added to OpenZFS

Please describe in documentation all known data corruption bugs and affected OpenZFS versions.

For example, in the OpenZFS FAQ.

Currently FAQ includes mention about only two bugs in the Sending and Receiving Streams FAQ chapter.

But, for example, known data corruption issue zfs send --dedup corrupts some files #7703 not described in current documentation at all.

Also, may be other already known data corruption bugs are not described in OpenZFS documentation?

How will this feature improve OpenZFS?

Users of affected versions of OpenZFS will know about danger and can prevent data corruption, for example, by upgrading to unaffected OpenZFS versions or by using known workarounds.

Additional context

For exampe, nginx security advisories described on special page: http://nginx.org/en/security_advisories.html

With clear description, which versions are vulnerable and which versions are not vulnerable.

[gmelikov]

@makhomed let's continue here

I'll duplicate your post:

@gmelikov, can you please clarify situation - probably I wrote my issue #11481 in the wrong bug tracker, I should get my issue #11481 from zfs bug tracker and create 1:1 copy of this issue in the openzfs-docs bugtracker?

https://github.com/openzfs/zfs/issues/11481

I think it's ok to track it here, no need to change.

From my point of view - this is critical information for production use of different versions of OpenZFS and for planning upgrades of older versions of the zfs at the production servers, but I can't find in one place in documentation description of all zfs critical bugs with data corruption and so on, something like at nginx security advisories page.

Issue #11481 already exists for more than two years, without any progress on it... Am I doing something wrong? Probably I use the wrong bug tracker for asking for OpenZFS documentation changes?

I don't know English very well - it is also not my native language, so I probably can't update OpeZFS documentation by myself, - also I don't know very well all OpenZFS critical bugs, which can lead to data corruption and denial of service / kernel panics.

I'm a non-native speaker too, but even in this position we can try to contribute to documentation too. We can always polish quality of previous contributions. Didn't want to lecture you here, just wanted to highlight that I'd be glad to review and comment any of your contributions. I've tried to make it easier to contribute when I reworked docs into https://github.com/openzfs/openzfs-docs repo.

This is the reason why I ask OpenZFS developers to update OpenZFS documentation and clarify the situation with OpenZFS bugs, which can lead to data corruption and denial of service / kernel panic. Or such information already exists in one place in the OpenZFS documentation, and I just have not found it?

Or OpenZFS right now is just in the development/beta quality phase and currently OpenZFS not indented for production use, and when I want rock solid and bulletproof filesystem for production use (like the nginx web server in the web servers area) - I should look for something else, for example well known OpenZFS alternative - BTRFS filesystem from the Oracle corporation? (It would be funny if it weren't so sad)

Not sure how you compare state of project and it's code stability by absence of some desired docs page.

It may be truly handy to have additional info on topic documented, this project is open for contributions. But please, understand that majority of contributors here do it in their spare time, your ultimatums about "maybe it's beta" just demotivates people. It's your right to make your decisions about using this project or not, but please don't make demands.

On topic - you can see majority of changes in changelog here https://github.com/openzfs/zfs/releases .

Fresh example:

Recently releases version zfs-2.1.11 contains a fix for a possible data corruption bug - this is means, what all production servers whih use 2.1.10 version of OpenZFS should be updated as soon as possible to latest released 2.1.11 version of OpenZFS.

But which versions of OpenZFS are affected to this possible data corruption bug and which versions of OpenZFS are not affected to this possible data corruption bug - I can't understand from just reading list of changes from the 2.1.11 version of OpenZFS.

Probably not only me, but also all other OpenZFS users, which are try to use the OpenZFS filesystem in the production.

OpenZFS filesystem is the best non-clustered filesystem in the entire world.

But OpenZFS documentation can be better, from my point of view.

As usual, contributions are welcome. This info can be found in changelog easily. Package maintainers in Linux distributions usually tracks such changes and push new releases and fixes for you. If you build package by yourself - you'll want to track it otherwise.

[makhomed]

I think it's ok to track it here, no need to change.

@gmelikov George, but this my issue is not related to OpenZFS code base, but only related to OpenZFS documentation.

In the GitHub exists function which allow transfer issue from one repository to another:

GitHub Docs: Transferring an issue to another repository

You have write access to both repositories, openzfs/zfs and openzfs/openzfs-docs this is means, what you can transfer this issue from openzfs/zfs repo to openzfs/openzfs-docs.

Can you please transfer this my issue from openzfs/zfs repo to openzfs/openzfs-docs?

I feel very uncomfortable using wrong repository for OpenZFS documentation discussions and improvements.

May be it is good idea also transfer from openzfs/zfs repo to openzfs/openzfs-docs all other issues related only to OpenZFS documentation and not related to OpenZFS code base at all?

I'm a non-native speaker too, but even in this position we can try to contribute to documentation too. We can always polish quality of previous contributions. Didn't want to lecture you here, just wanted to highlight that I'd be glad to review and comment any of your contributions. I've tried to make it easier to contribute when I reworked docs into https://github.com/openzfs/openzfs-docs repo.

Ok, thank you, reworked docs into https://github.com/openzfs/openzfs-docs repo - is good idea, I think.

If I will find some bugs it the OpenZFS documentation - I will open issue in openzfs/openzfs-docs or even write PR, when time permits. I hope Google translate will help me to improve quality of my English.

But please, understand that majority of contributors here do it in their spare time, your ultimatums about "maybe it's beta" just demotivates people. It's your right to make your decisions about using this project or not, but please don't make demands.

Sorry, I do not have intent to demotivate OpenZFS developers, because OpenZFS is very good job and it is the best file system in the entire world. Also OpenZFS and nginx is the critical part of my infrastructure, I already can't build modern infrastructures without OpenZFS and nginx at all.

I use OpenZFS in the production and it may be good idea to have roadmap, which versions of zfs are buggy and shoud not been used in the production, and which versions of zfs did not contains known critical bugs and can be used in production.

For the nginx web server project this information about affected versions described in the one page: https://nginx.org/en/security_advisories.html

Is it possible to have something like this for the OpenZFS project?

As usual, contributions are welcome. This info can be found in changelog easily. Package maintainers in Linux distributions usually tracks such changes and push new releases and fixes for you. If you build package by yourself - you'll want to track it otherwise.

I use Rocky Linux 9.1 - it is free and open source variant of Red Hat Enterprise Linux 9.1, and also I use OpenZFS 2.1.x from the official OpenZFS repo for the Enterprise Linux 9.x - zfs-dkms variant, as more stable and more robust solution.

dnf install -y epel-release
dnf install -y kernel-devel
dnf install -y zfs

Side note: dnf install -y epel-release is not enough for correct enabling EPEL repo, because for correct enabling EPEL repo need first to execute command dnf config-manager --set-enabled crb for Rocky Linux 9.1 and other similar command for other distros. More details about this -- at the EPEL homepage: Extra Packages for Enterprise Linux (EPEL).

For current version of Rocky Linux 9.1 I just use latest stable version of zfs, upgrading systems from time to time, no problems here at all:

# zfs version
zfs-2.1.11-1
zfs-kmod-2.1.11-1

But I have also old systems - Rocky Linux 8.x, CentOS 7.x with kABI-tracking kmod, and I try to not touch this systems because if kABI-tracking kmod and Linux kernel is not match - i will obtain operating system without zfs at all, and without access to all critical data stored on the zfs datasets. So I prefer to do not touch these old and very old systems without extreme necessity, there is such a saying: "if it works - do not touch it". Because I am not sure what every "new" version is more stable and have less critical bugs than some "old" version.

But if some old zfs versions have known critical bugs, which can lead to data corruption - these old systems should be upgraded to new versions of zfs, probably with switching from the kABI-tracking kmod to DKMS style packages.

I search in the OpenZFS documentation for the full list of zfs versions with critical bugs, but can't find it. Probably because such full list of the not acceptable for production use zfs versions (or the full list of acceptable for production use zfs versions) did not exists in the OpenZFS documentation?

P.S.

I apologize for the long message, brevity is not one of my virtues.

[gdevenyi]

#13612

[makhomed]

Also, related #13755, almost 1:1 as this my issue and my situation:

Describe the feature would like to see added to OpenZFS

I'm about to upgrade a bunch of old boxes running a mix of 0.6 and 0.7 releases. I'm not going to just straight up upgrade to the latest version because i value stability over new features, so i would like to know in advance which blocking bugs are still present (fix not backported) in which releases before i venture on this journey.

Is this information already available somewhere?

How will this feature improve OpenZFS?

This will help users plan their upgrade path and avoid unpleasant surprises.