mds: revert referent inode work

[vshankar]

The motive was to remove the global snap realm and referent inodes was the prerequisite for that. Unfortunately, removing the global snap realm is turning out to be much complicated than it was initially thought of. Therefore, to reduce the risk of things breaking in tentacle given that branching tentacle is round-the-corner and that global snap realm is not going to go away in Tentacle, it makes sense to revert this work (although I do this with a heavy heart).

However, we have a much better understanding of the snap realm machinery now - kudos to the awesome work put in by @kotreshhr on this. This is not a wasted effort and is certainly going to help when this is worked on again (post tentacle branching and this time with a clear way forward).

Contribution Guidelines

• To sign and title your commits, please refer to Submitting Patches to Ceph.

• If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.

• When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an x between the brackets: [x]. Spaces and capitalization matter when checking off items this way.

Checklist

• Tracker (select at least one)
  • References tracker ticket
  • Very recent bug; references commit where it was introduced
  • New feature (ticket optional)
  • Doc update (no ticket needed)
  • Code cleanup (no ticket needed)
• Component impact
  • Affects Dashboard, opened tracker ticket
  • Affects Orchestrator, opened tracker ticket
  • No impact that needs to be tracked
• Documentation (select at least one)
  • Updates relevant documentation
  • No doc update is appropriate
• Tests (select at least one)
  • Includes unit test(s)
  • Includes integration test(s)
  • Includes bug reproducer
  • No tests

Show available Jenkins commands

• jenkins test classic perf Jenkins Job | Jenkins Job Definition
• jenkins test crimson perf Jenkins Job | Jenkins Job Definition
• jenkins test signed Jenkins Job | Jenkins Job Definition
• jenkins test make check Jenkins Job | Jenkins Job Definition
• jenkins test make check arm64 Jenkins Job | Jenkins Job Definition
• jenkins test submodules Jenkins Job | Jenkins Job Definition
• jenkins test dashboard Jenkins Job | Jenkins Job Definition
• jenkins test dashboard cephadm Jenkins Job | Jenkins Job Definition
• jenkins test api Jenkins Job | Jenkins Job Definition
• jenkins test docs ReadTheDocs | Github Workflow Definition
• jenkins test ceph-volume all Jenkins Jobs | Jenkins Jobs Definition
• jenkins test windows Jenkins Job | Jenkins Job Definition
• jenkins test rook e2e Jenkins Job | Jenkins Job Definition

[batrick]

Make it so!

[gregsfortytwo]

I don't think we should revert this until/unless we have another solution for https://tracker.ceph.com/issues/67102.
(In fact I've asked @kotreshhr to make sure we are testing the referent inodes in our regular suites a bit more often.)

We can talk about Tentacle options if we think it needs more bake time, I guess?

[batrick]

I don't think we should revert this until/unless we have another solution for https://tracker.ceph.com/issues/67102. (In fact I've asked @kotreshhr to make sure we are testing the referent inodes in our regular suites a bit more often.)

We are not even sure yet that the referent inode patchset will fix that problem as we do not have a test for it. (Getting rid of the global snaprealm should probably do it but there should be tests which replicate the problem and verify that the new behavior is correct.)

We can talk about Tentacle options if we think it needs more bake time, I guess?

The consensus we (Venky, Kotresh, and I) reached was that additional time spent reviewing is appropriate. We also need time to evaluate whether other possibly better options exist now that Kotresh is significantly more confident in the related code.

The scale of the change deserves a full release of bake time in main. Delaying the revert until after tentacle is branched only complicates the revert significantly. Doing it now avoids this.

[github-actions]

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

[vshankar]

@kotreshhr rebased and pushed. PTAL. I will merge this once approved and port the changes to tentacle.

[kotreshhr]

@kotreshhr rebased and pushed. PTAL. I will merge this once approved and port the changes to tentacle.

@vshankar Aren't we reverting this only in tentacle and keeping it in main ?

[vshankar]

@kotreshhr rebased and pushed. PTAL. I will merge this once approved and port the changes to tentacle.

@vshankar Aren't we reverting this only in tentacle and keeping it in main ?

@batrick requested a design doc before the changes can be accepted.

[vshankar]

@kotreshhr rebased and pushed. PTAL. I will merge this once approved and port the changes to tentacle.

@vshankar Aren't we reverting this only in tentacle and keeping it in main ?

@batrick requested a design doc before the changes can be accepted.

I misspoke a bit. Maybe we wanted to keep this change in main and revert it only in tentacle.

My take on the referent inode work is that if PR #62682 takes care (in the interim) for the old_inodes issue (which, btw, we do not have a reproducer), then the referent inode changes can be reworked before merging with things like design documents, adequate tests, etc..

I do not have a strong opinion on this though which means we can always keep this change in main and the things I mentioned incrementally.

EDIT:s/string/strong

[vshankar]

jenkins test dashboard