The goal of academic research is to explore ideas, which are judged by submitting papers to conferences for review, and to train the next generation of academics (i.e., graduate students) in coming up with ideas, proving them, and then writing up said ideas and the proof that they work well. It is not to create a production quality software, which is an orthogonal set of goals and skills.
The key thing to remember is that THERE IS NOTHING WRONG WITH THIS ACADEMIC PROCESS. I go to the Filesystems and Storage Technology (FAST) conference, where many of these BetrFS papers were published, to harvest ideas which I might use in my production systems, and of course, to see if any of the graduate students who have decided that the academic life is not for them, whether they might come to work for my company[1]. I personally find the FAST conference incredibly useful on both of these fronts, and I think the BetrFS papers are super useful if you approach them from the perspective of being a proving ground for ideas, not as a production file system.
So it's unfortunate that people seem to be judging BetrFS on whether they should "trust my data/workloads to such systems", and complaining that the prototype is based on the 3.11 kernel. That's largely irrelevant from the perspective of proving such ideas. Now, I'm going to be much more harshly critical when someone proposes a new file system for inclusion in the upstream kernel, and claiming that it is ready for prime time, and then when I run gce-xfstests on it, we see it crashing right and left[2][3]. But that's a very different situation. You will notice that no one is trying to suggest that BetrFS is being submitted upstream.
A good example of how this works is the iJournaling paper[4], where the ideas were used as the basis for ext4 fast commits[5]. We did not take their implementation, and indeed, we simplified their design for simplicity/robustness/deployment concerns. This is an example of academic research creating real value, and shows the process working as intended. It did NOT involve taking the prototype code from the jJournaling research effort and slamming it into ext4; we reimplemented the key ideas from that paper from scratch. And that's as it should be.
[1] Oligatory aside: if you are interested in working on file systems and storage in the Linux kernel; reach out to me --- we're hiring! My contact information should be very easily found if you do a Google search, since I'm the ext4 maintainer
The key thing to remember is that THERE IS NOTHING WRONG WITH THIS ACADEMIC PROCESS. I go to the Filesystems and Storage Technology (FAST) conference, where many of these BetrFS papers were published, to harvest ideas which I might use in my production systems, and of course, to see if any of the graduate students who have decided that the academic life is not for them, whether they might come to work for my company[1]. I personally find the FAST conference incredibly useful on both of these fronts, and I think the BetrFS papers are super useful if you approach them from the perspective of being a proving ground for ideas, not as a production file system.
So it's unfortunate that people seem to be judging BetrFS on whether they should "trust my data/workloads to such systems", and complaining that the prototype is based on the 3.11 kernel. That's largely irrelevant from the perspective of proving such ideas. Now, I'm going to be much more harshly critical when someone proposes a new file system for inclusion in the upstream kernel, and claiming that it is ready for prime time, and then when I run gce-xfstests on it, we see it crashing right and left[2][3]. But that's a very different situation. You will notice that no one is trying to suggest that BetrFS is being submitted upstream.
A good example of how this works is the iJournaling paper[4], where the ideas were used as the basis for ext4 fast commits[5]. We did not take their implementation, and indeed, we simplified their design for simplicity/robustness/deployment concerns. This is an example of academic research creating real value, and shows the process working as intended. It did NOT involve taking the prototype code from the jJournaling research effort and slamming it into ext4; we reimplemented the key ideas from that paper from scratch. And that's as it should be.
[1] Oligatory aside: if you are interested in working on file systems and storage in the Linux kernel; reach out to me --- we're hiring! My contact information should be very easily found if you do a Google search, since I'm the ext4 maintainer
[2] https://lore.kernel.org/r/YQdlJM6ngxPoeq4U@mit.edu
[3] https://lore.kernel.org/all/YQgJrYPphDC4W4Q3@mit.edu/
[4] https://www.usenix.org/conference/atc17/technical-sessions/p...
[5] https://lwn.net/Articles/842385/