I don’t think I dismissed the value of the paper. I pointed out that implementation may not be that good, and best paper award and quality of the implementation most of the time are not correlated.
You dismissed the value of the paper about ten times in a row, barely stopping for breath. Some of the tone is found in which thing goes on what side of the word "but", some in other words, but generally you really messed it up if you wanted to avoid insulting the authors and dismissing the value of research like this. There is an enormous gulf between a comment like yours
> That’s all fine and dandy, but [...] Winning best paper awards doesn’t say a thing about the implementation [...] the goal of PhD students is to publish papers [...] I couldn't trust [this]
and a comment like this
> This is a really impressive project. Obviously this is deeply academic, but since I am so impressed, I wonder what the plans are for this (or the same idea in a new fs) to reach the kind of commercial quality where I can use it in a production system.
If you were so aware of the general nature of academic research vs battle-tested implementations, then you would also know that filesystems are so incredibly complicated that the latter invariably takes on the order of 10+ years from a big team to create. When you forget this fact and say that a few-years-old implementation probably sucks because it's from academia, you're ignoring that NOBODY could have made it production-ready in that time, not even Microsoft or Apple or Oracle. Why would you criticise it on this basis? Choosing to do that was the biggest dismissal of the value of the work. Instead, you buried what was in effect a compliment (this would be useful for my production systems) under ten layers of insults.
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.
cormacrelf|4 years ago
> That’s all fine and dandy, but [...] Winning best paper awards doesn’t say a thing about the implementation [...] the goal of PhD students is to publish papers [...] I couldn't trust [this]
and a comment like this
> This is a really impressive project. Obviously this is deeply academic, but since I am so impressed, I wonder what the plans are for this (or the same idea in a new fs) to reach the kind of commercial quality where I can use it in a production system.
If you were so aware of the general nature of academic research vs battle-tested implementations, then you would also know that filesystems are so incredibly complicated that the latter invariably takes on the order of 10+ years from a big team to create. When you forget this fact and say that a few-years-old implementation probably sucks because it's from academia, you're ignoring that NOBODY could have made it production-ready in that time, not even Microsoft or Apple or Oracle. Why would you criticise it on this basis? Choosing to do that was the biggest dismissal of the value of the work. Instead, you buried what was in effect a compliment (this would be useful for my production systems) under ten layers of insults.
tytso|4 years ago
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.