Linux 6.8-rc2
-
Linux 6.8-rc2
So we had a number of small annoying issues in rc1, including 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.
There was also a btrfs bug wrt zstd-compressed inline extents, although (somewhat) happily that wasn't in rc1 and got noticed and reverted fairly quickly, so hopefully it didn't hit very many people. It did me.
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.
So go out and test. It's safe now. You trust me, right?
Linus -
[PATCH] eventfs: Have inodes have unique inode numbers
Linus suggested to use the same inode numbers to make it easier to implement getdents(), as it was creating inodes just for generating a unique and consistent inode number. Linus suggested to just use the same inode for all files and directories.
Later it was discovered that having directories with the same inode number would mess up the "find" command, but Linus found that on 64 bit machines, there was a hole in the eventfs_inode structure due to alignment that could be used to store the inode numbers for directories. That fixed the directory issue, but the files still had their own inode number.
The 'tar' command uses inode numbers for determining uniqueness between files, which this would break. Currently, tar is broken with tracefs because all files show a stat of zero size and tar doesn't copy anything. But because tar cares about inode numbers, there could be other applications that do too. It's best to have all files have unique inode numbers.
Copy the get_next_ino() to tracefs_get_next_ino() that takes a "files" parameter. As eventfs directories have a fixed number of files within them, the number of inodes needed for the eventfs directory files is known when the directory is created. The tracefs_get_next_ino() will return a new inode number but also reserve the next "files" inode numbers that the caller is free to use. Then when an inode for a file is created, its inode number will be its parent directory's inode number plus the index into the file array of that directory, giving each file a unique inode number that can be retrieved at any time.
-
Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same
Well, the fact that it hits snapshots, shows that the real problem is just "tar does stupid things that it shouldn't do".
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.
An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed.
Linus
-
Linus Torvalds flames Google kernel contributor over filesystem suggestion
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.
Update
Now in LWN too:
-
Kernel prepatch 6.8-rc2 [LWN.net]
Linus has released 6.8-rc2 for testing. ""So go out and test. It's safe now. You trust me, right?""