The iJournaling paper was published in 2017 (and like many papers, it took multiple rounds of paper submissions before it was finally accepted; the academic procress is rigorous, and many program committees are especially picky).
The jJournaling ideas hit the upstream kernel in 2021 as ext4 fast commits, and no I don't consider it production ready yet. If the fast commits journal gets corrupted, it's possible that the file system will not be automatically recoverable, and may even lead to kernel crashes. I'd give it another year or so before it's completely ready for prime time.
But the other reason for the four year delay between 2017 and 2021 is because I had to find the business justification (and after that, the budget and head count) to invest the SWE time to actually implement the idea. A lot of people want new sexy file system features, but very few people are willing to PAY for them. So part of the job of an open source maintainer is not just to perform quality control and create a technical roadmap, but also to help the developers workin on that subsystem to make business cases to their respective employers to make a particular investment. The dirty little secret is that most people are pretty happy with the file systems as they currently exist; the bottleneck is often not the file system, and while certain file system features are _nice_, they very much aren't critical --- or at least not enough that people are willing to pay the SWE cost for them.
The jJournaling ideas hit the upstream kernel in 2021 as ext4 fast commits, and no I don't consider it production ready yet. If the fast commits journal gets corrupted, it's possible that the file system will not be automatically recoverable, and may even lead to kernel crashes. I'd give it another year or so before it's completely ready for prime time.
But the other reason for the four year delay between 2017 and 2021 is because I had to find the business justification (and after that, the budget and head count) to invest the SWE time to actually implement the idea. A lot of people want new sexy file system features, but very few people are willing to PAY for them. So part of the job of an open source maintainer is not just to perform quality control and create a technical roadmap, but also to help the developers workin on that subsystem to make business cases to their respective employers to make a particular investment. The dirty little secret is that most people are pretty happy with the file systems as they currently exist; the bottleneck is often not the file system, and while certain file system features are _nice_, they very much aren't critical --- or at least not enough that people are willing to pay the SWE cost for them.