A manual about zpool could not be imported ?

[homerl]

Hello Guys

I have seen many cases of zpool import failures leading to data loss in the community and mailing lists.

I and my friends have also encountered similar scenarios. Moreover, ZFS monitoring is very important. I have also encountered scenarios where small errors are lost every day, which eventually accumulate into an irreversible error

In the year 2024, it's shocking to see people still relying on 'zpool import -FX'. This practice is incredibly dangerous and should be avoided at all costs.

People use ZFS because it is a large storage pool that can effectively handle massive amounts of data.

Every time I encounter a zpool import failure, whether assisting others or recovering my own data, a chill runs down my spine.

From a different perspective, I believe ZFS's metadata protection is inadequate. In many cases, the data itself is intact, but the metadata or checksums are corrupted. This leads to even valid data being displayed incorrectly.

1. readonly is very important
2. The combination of ”-F -n“ and ”echo $?“ can address certain issues.
3. Rolling back to a previous or next transaction (txg)
4. zfs_max_missing_tvds_per_vdev, and spa_load_verify_metadata can also help save data for many people

Would it be possible to create a community document to standardize the procedures?
Thanks.

[rincebrain]

One of the problems with preparing such a document, is that some/most of the steps won't be the correct thing to do in some cases, and people will just frantically copy-paste every command in it to try and get their data back before talking to anyone, then complain that "zpool import --delete-all-data" deleted their data no matter how big a "do not run this except in this one very specific case" you put around it.

(I would also argue the problem is not necessarily that the metadata protection is inadequate, but that people keep merging code with the philosophy "ship it as the only testing", unless you have specific examples in mind.)

[rincebrain]

Sure, I'm not saying it would have no value, but those would be my concerns about a guide which is essentially "these are all the most dangerous things to copy-paste in one place" being provided by the project.

[homerl]

Thank you, I got it.
Everything is a double-edged sword. It depends on your perspective and how you use it.

[rincebrain]

I suppose I should clarify, my specific concern is that there is a perception that things recommended by the developers are "safe", in my experience, leading to backlash if that expectation is violated.

I'm not against the idea, I actually started writing one in response to this discussion, I just don't know what I think a reasonable way to provide it would be that would not result in a significant uptick in footgun usage, given the number of times I've had to explain to people that zpool upgrade is not something you should casually run just because zpool status told you you could.

"In theory", one could do something like streamline the various lovecraftian horror dances people do for pool recovery into zhack or some other command, and make it ask people to please report a bug if they have to use it, since that should never be necessary, and we don't want to only find out many moons too late that some people have just been working around their pool breaking every week or so for years until it's too broken to work any more. But that feels worse, to my mind, since I think most people's mental model for anything called "fsck" or "repair" is that it's going to be safe to run, and it's very difficult to make some of these safe.

@behlendorf do you have thoughts on this? Like I said, I started writing something up, and I'll probably finish it in a day or so, but I'm not sure what I would suggest doing with it, for the reasons I described - but if other people think the good outweighs the harm, we could certainly ship such a thing in the online documentation, if nothing else.

[homerl]

To be honest, I didn't know running ”zpool upgrade“ casually could be risky.
It seems like having this guide would be helpful

[rincebrain]

It's not risky, per se, but it is, as the message obliquely warns you, irreversible.

action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.

e.g. "if you run zpool upgrade on 2.2, you may not be able to import the pool on 2.1 any more".

Particularly since a number of features get marked active immediately after being enabled and never stop being active...

[homerl]

It may not solve most of the problems, but it can prevent the current situation from worsening further and help people calm down.
It's just a warning signs