This is a huge change. Many years ago there was an idea to replace the important occurrences of ceph_assert() with ceph_assert_always() and compile-out everything else for production builds. The problem is of course in judging what's essential across the entire code-base.

If you want to resurrect the effort, I would propose to bring the topic to next Ceph Development Montly meeting.

How much of CPU overhead does this squeeze?

I havn't isolated this patch in my measurements, but I think it's a small piece. Most users can probably afford it, but we at IONOS have serious performance problems with the MDS, so we want to squeeze out every bit we can (and we will leave patches that are not accepted upstream in our private fork).
I do however not get the point of ceph_assert_always() - by design, assertions are only for detecting bugs in debug builds - is this for people not confident enough in their code, and they still think they need guaranteed assertions in release builds? Why not regular runtime checks? (I'm not a fan of redundant runtime checks either. Get the code right, verify it with fine-grained unit tests, and remove all the unnecessary checks at release-runtime.)

I havn't isolated this patch in my measurements, but I think it's a small piece.

I share this intuition on the CPU overhead.
I don't see benefit in optimizing the size of the executable as most of the asserts' code already is (IIRC; "should be" for sure) in cold sections, so they shouldn't inflict a cost even in terms of memory but just address space.

I do however not get the point of ceph_assert_always()

Yeah, the effort to differentiate the asserts is long dead. Perhaps we should say this explicitly and switch everybody to ceph_assert().

by design, assertions are only for detecting bugs in debug builds - is this for people not confident enough in their code, and they still think they need guaranteed assertions in release builds?

Hah, I don't think a programmer should be confident enough till having a mathematical proof of correctness.

Why not regular runtime checks? (I'm not a fan of redundant runtime checks either.

What do you mean by regular run-time checks? Sanitizers?

Get the code right, verify it with fine-grained unit tests, and remove all the unnecessary checks at release-runtime.)

These assertions saved me so much investigation time in the wild that I really appreciate their presence in productions builds. As there is no clear evidence of high cost, I'm for rejecting the idea. Yet, if you think you have strong enough arguments, I'm happy to discuss at CDM (see https://tracker.ceph.com/projects/ceph/wiki/Planning).