Francesco Allertsen - Issue #65

This article is the story of how GitLab developers found (and fixed) a bug in the Linux kernel that created problems with GitLab itself.

I really liked this article because it’s a real in-depth description on how they debugged the whole stack and went from reproducing consistently the bug to communicating with the different communities (NFS and Linux kernel) to fixing it in the end.

Not only it’s a very interesting debugging story, but it also shows the power of open source and communication. This shows how important it is to work together with open and welcoming communities to find a way to fix a problem in the software not only for you but for everyone who is using that particular software, which may not have triggered the bug yet, but they may in the future.

This is the short description of the article, and it’s quite interesting (at least for me).

One of the biggest scalability problem (in general) is storage. More or less every application needs to store some sort of data/information, and although it could be quite trivial to store few GB of information, it will start to become less trivial the more informations you need to store.

This is, of course, also valid for GitLab, where they need to store all the Git data about all the repositories of their customers. This article explains exactly this: how they managed to create “Gitaly”, which is an internal service to be able to store git data with horizontal scalability (meaning that, in theory, there is no limit on how much data can be stored). This is also interesting because if you want to know more about Gitaly, the source code is open source, so you can have a look at it and understand it and even use the same concept for one of your projects that require to store a lot of information.

This article is a summary explanation of a paper from WeChat published in SoCC 2018.

I’m not going to put the abstract here, you can easily find it in the paper, but the overall idea of the paper is to show how WeChat managed to solve the problem of overload control, and they presented DAGOR, the system they developed and they are using in production to solve this problem.

I’m just going to leave here a quote from the paper on what kind of scaling we are talking about.

I have been using Slack for quite some time, both for work and joining some online communities, but, for some reason, over time I have seen myself using it less and less, and I see now (working with other companies) that everyone have Slack, but it’s not used a lot, it’s mostly just there in case it’s needed, and more for private conversations and not in the channels.

This is a very well written story that I can relate to, and these are the main topic discussed in it: