Conversation
Vegard Nossum
vegard@mastodon.social
git.kernel.org was serving 37M of binary garbage after the end of </html> when viewing some files under tree/ 🤔 Seems to have been resolved now, though... anybody know what that's about?
1
1
1
K. Ryabitsev
monsieuricon
@vegard it's a heisenbug in cgit. The way it does disk cache management can result in cache filename collision. In such cases, the process overwrites the start of the cache file with new content and truncates the rest, but under certain elusive conditions the truncating doesn't happen.
2
0
5
AndresFreundTec
AndresFreundTec@mastodon.social@monsieuricon @vegard ISMT the cache replacement should instead create the new contents in a temporary file and rename the file into place when done?
3
0
0
AndresFreundTec
AndresFreundTec@mastodon.social@monsieuricon @vegard FWIW, in postgres we've seen ftruncate() failures in production due to signal delivery. Even with SA_RESTART.
0
0
0
K. Ryabitsev
monsieuricon
@AndresFreundTec @vegard I'll be happy if upstream cgit fixes this, because it's been a recurring problem over the past decade. :)
0
0
0
Vegard Nossum
vegard@mastodon.social@AndresFreundTec @monsieuricon The code is https://git.zx2c4.com/cgit/tree/cache.c, there's a rename() call in there. Unfortunately I didn't find any high-level documentation on how it's designed to work. Also didn't find the time to look closer at it.
1
0
0
K. Ryabitsev
monsieuricon
@vegard @AndresFreundTec Note, that it's possible that I'm completely mixing up my codebases and the truncate problem occurs with something else entirely, not with cgit. It's been a long while since I looked at it -- but it does seem consistent with the kind of problem we're seeing.
0
0
1