On Wed, Jan 15, 2025 at 08:21:04AM +1100, Dave Chinner wrote: > On Tue, Jan 14, 2025 at 08:57:51AM -0500, Theodore Ts'o wrote: > > P.S. If you want to push back on this nonsense, Usenix program > > committee chairs are very much looking for open source professionals > > to participate on the program committees for Usenix ATC (Annual > > Technical Conference) and FAST (File System and Storage Technologies) > > conference. > > The problem is that the Usenix/FAST paper committees will not reach > out to OSS subject matter experts to review papers that they have > been asked to review for the conference. > > Let me give you a recent example of a clear failure of the FAST > paper committee w.r.t. plagarism. > > The core of this paper from FAST 2022: > > https://www.usenix.org/conference/fast22/presentation/kim-dohyun > > "ScaleXFS: Getting scalability of XFS back on the ring" > > is based on the per-CPU CIL logging work I prototyped and posted an > RFC for early in 2021: > > https://lore.kernel.org/linux-xfs/20200512092811.1846252-1-david@xxxxxxxxxxxxx/ > > The main core of the improvements described in the ScaleXFS paper > are the exact per-cpu CIL algorithm in that was contained in the > above RFC patchset. > > That algorithm had serious problems that meant it was unworkable in > practice - these didn't show up until journal recovery was tested > and it resulted in random filesystem corruptions. I didn't > understand the root cause of the problem until months later. > > These problems were all based on failures to correctly order the > per-CPU log items in the journal due to the per-CPU CIL being > inherently racy. The algorithm I proposed 6 months later (and > eventually got merged in July 2022) had significant changes to the > way the per-CPU CIL ordered operations to address these problems. > > IOWs, object ordering on the CIL is the single most important > critical correctness citeria for the entire journalling algorithm > and hence a fundamental algorithmic constraint for the per-CPU CIL > implementation. > > However, the ScaleXFS paper does not make any mention of this > fundamental algorithmic constraint - I did not publish anything > about this constraint until the November 2022 patch set.... > > There were more clear tell-tales in the paper that indicate > that the "research" was based on that early per-CPU CIL RFC I > posted, but I won't go into details. > > I brought this to the FAST committee almost immediately after I was > able to review the paper (a couple of days after the FAST conference > itself). I provided them with all the links to public postings of > the algorithm, detailed analysis of the paper and publicly posted > code, etc. In response, they basically did nothing and brushed my > concerns off. It would take weeks to get any response from the paper > committee, and the overall response really felt like the Usenix > people simply didn't care at all about what was obviously plagarised > work. > > IOWs, the Usenix/FAST peer review process for OSS related papers is > broken, and they don't seem to care when experts from the OSS > community actually bring clear cases of academic malpractice to > them... Yeah, that does look like misconduct, of the type that merits a boycott...
