Linus Torvalds flames Google kernel contributor over filesystem suggestion
Kernel 6.8-rc2 debuts after very robust discussion about 'inodes'
Linus Torvalds has dished up one of his most strongly worded Linux kernel mailing list posts in years, lashing a contributor from Google for his suggestions regarding filesystems.
The subject of Torvalds's ire is inodes, which as Red Hat puts it are each "a unique identifier for a specific piece of metadata on a given filesystem."
Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using
tar to archive files. Torvalds countered that inodes have had their day.
"Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed."
But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers.
Torvalds's response used language, and tone, that has seldom been seen in recent years.
Recall that in 2018 he announced a decision to take a break and seek help after apologizing for what he described as "flippant attacks in emails" to fellow Linux programmers and project contributors that he admitted were "both unprofessional and uncalled for. Especially at times when I made it personal … I know now this was not OK and I am truly sorry."
Torvalds's contrition came, in part, because the Linux kernel mailing list is effectively a workplace for many contributors. Abusive posts do not make for a happy workplace. And, given that Linux relies on volunteer contributors and maintainers, a nasty workplace environment has potential to hurt the project.
In response to Rostedt's suggestion about unique inode numbers, Torvalds opened: "Stop making things more complicated than they need to be."
Then he got a bit shouty.
"And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap."
Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter – which Rostedt later acknowledged.
By then, however, Torvalds had flamed him as follows:
You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE.
Debate continued for some time, in a cooler tone, with Torvalds offering suggestions on what he felt would be a better approach to the issues Rostedt hoped to address. The penguin emperor wrote he did not intend to pursue the matter immediately, as "I wasted enough time on this and I'm way behind in my other responsibilities, so this is not something I can work on now."
Rostedt's reply offered the following – perhaps pointed – observation:
Ironically, one of the responsibilities that I've been putting off to fix up eventfs was writing that document on a support group for maintainer burnout. :-p
- The Land Before Linux: Let's talk about the Unix desktops
- Linus Torvalds postpones Linux 6.8 merge window after being taken offline by storms
- Linus Torvalds releases Linux 6.6 after running out of excuses for further work
- Long-term support for Linux kernels is about to get a lot shorter
Come Sunday, Torvalds was posting on happier matters: the debut of version 6.8-rc2 of the Linux kernel.
Torvalds noted that rc1 included "an amdgpu scheduling bug that could cause a hung desktop (that would *eventually* recover, but after a long enough timeout that most people probably ended up rebooting instead."
"That one seems to have hit a fair number of people."
Torvalds himself was troubled by a btrfs bug that thankfully didn't make it into rc1 as it was noticed before release.
"Anyway, I hope that with rc2, we're now in the more stable part of the release cycle, with those kinds of problems that might affect a lot of testers sorted out. So hopefully the fixes will be more subtle and not affect common core setups," he wrote.
"So go out and test. It's safe now. You trust me, right?"
Sure – if the question is only about developing a kernel. ®