GitLab Support Team, 17 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Using Strace to Understand GitLab - Part 2: Git

Description

Walkthrough on using Strace to understand how Git interacts with the filesystem.

0:00 Intro
1:00 Tracing 'git status'
10:20 Tracing 'git commit'

Part 1: https://www.youtube.com/watch?v=fcY5pPUq35U
Part 3: https://www.youtube.com/watch?v=J-GkU7Mmqy4
Part 4: https://www.youtube.com/watch?v=dgJH4wpR5OE

A

Hi, everyone welcome to episode two of our s tracing tutorial. um So in this episode we'll go through s tracing a couple different get commands just to see some more c programs in action and understand a little bit better. How git works under the hood all right, so let's go ahead and get started.

A

Okay, so I've got a git repo right here. It's got one command in it, just a single file and I have added a modified this file, that's in there, and so we want to understand what is git status doing under the hood. So if we s trace this.

A

Take a look at okay, um so, like last time we can see we exec ve this time, it's kit status and you can see the actual binder executed is user local bit git.

A

Then we check what our heap is using brk. We once again access ldso to preload, and then we start opening up our shared library. So in this case we're going to lib z for compression and if we look at what libraries are just able to get, we've got the z liberty, the pthread and lib c, along with uh ld linux and linux, vdso uh associated shared libraries, okay, so we've went over the process of opening a shared library last time, so we'll just skip by all these here.

A

uh The p thread anything else we're loading. Let's see there. Okay, we protect our memory, start setting our seek actions a couple of times all right. We open a dev null for some reason and then immediately close it uh allocated more memory to the heap. We start checking out locale. Now we saw this last time so we'll skip by locale as well. Okay, all right!

A

um So now we are trying to check for a git config file, so you can see we're actually going to a number of different places, um so we go to use your local etsy, git config and that doesn't exist user or myom directory.config that get config that doesn't exist. I do have a git config file, though um so it confirms adds this. Then it opens that and then it stats it twice for some reason and then reads it in so there's my email and name and then it reaches end of file and closes it out.

A

Then it gets its current working directory with get cwd, which is the example git repo uh it stats it stats.getdirectory.

A

uh Then it tries to open up uh the head file and succeeds reads that our current branch is master closes that out checks. If there's a commander checks, if there's an object, yep that exists, ref success, it opens up the project.

A

Config reads that in that's just the default git config for a new project uh closes that up. Okay, then it starts the kit directory checks. If the common directory exists, it does not looks for the user. Local etsy, git config, again still doesn't exist, looks for my. My home, directory.config getconfig still doesn't exist, finds my config opens it again, stats it twice again. Reads it again, a little bit of duplication here, for whatever reason uh we're doing it again: okay, third time's, the charm- I guess okay, so we're done with that.

A

We get a working directory and then we change to the directory, we're already in all right. We once again check for common directory there's a fair amount of duplicated work. If you look at the actual timestamps, though we're not really wasting any significant amount of time, we're a few milliseconds in so even though we've done the same thing same thing three times in a row for some reason, we have not actually wasted the user's time, so that's something anyway.

A

Okay, we've read our get config, for I think the fourth time at that point all right. So here's where we start getting interesting. um So here we are locking the recheck for the index it does exist. Then we read it in the map. The index close it, oh actually not quite the interesting part. Yet, okay, a little bit more locale, we set a timer.

A

We stat the a file which is the only file in the actual repo, proper.

A

And then here we know we're not here here we are okay and then here we create index.lock, and so this this o exclusive flag here, which you can see on the man page here on the right, well, basically says that if this file already exists, then um where the open a command will fire out. So this way we can be sure that no other applications have or git processes have a lock on this repo.

A

So we are safe to go in and and check that we're not going to have things checked or changed out from under us. Okay, we set a few more signal handles for some reason.

A

um We get our process so get pid and you can see that the values returned is the actually the process the s3 says well, in this case, uh okay, we check for head re-open head or read head, which is still master after last time as well. um Okay, let me find rest heads master, there's the current uh reference for that we check for there any pack, reps they're, not or check for tags and check for any other heads. None of these files are just.

A

This is a very basic repo right now we find a which is the only file that's in there.

A

We open head again. I read it again. This is really going to be a trend here. Isn't it okay, we check for those files again.

A

And uh okay, we're checking for what files are in the get get references directory. So we get four entries back from that. um Let me check for what's in there stack those files.

A

Actually the directories. In this case you can sell from that. Okay, we run get debts again. This time no more entries are returned, so we know we've iterated through that directory close that out, we look again for pack, refs still doesn't exist.

A

uh We look for a pac file. uh Looks like this does exist, yep, okay, there I'm sorry! This is a directory, but it's empty. There's nothing in there. Okay,.

A

Yeah, there's only one comma down here, so we haven't actually created a pack file. Yet, okay, um so we've got our objects file. We map that read only and close that out.

A

Yeah and then we immediately unmap it since it's so tiny, I'm sure that we immediately get really able to read that immediately and it's done with it. Okay, we check for some other common files graph shadow commit graph. This is git 2.27, so the most recent release at this point on july 17th 2020.

A

Okay, we open up our object again.

A

And map it again close it out again allocate a little more memory, then free the mem app and here we're creating some scratch space, a fair amount in a huge amount using mem map.

A

It went up for object again.

A

um I think we're almost done. Okay, then we open up the current directory. We check for what entries are within that we look for other common files, all right. So at this point we've completed searching through the repo, so we can close our index.lock and then use unlink to delete it so that file has been removed. It's no longer there, so we've signaled to any other git processes that might be in here that they are free to go ahead and modify the index.

A

If I need to okay, let me read head again and read the ref for that, and then we start writing out the console.

A

So we have one file, that's not changed and here's all the text that we saw- and you can see here- it's just the ascii uh color code that we see in the uh terminal itself, okay and then once we've done, writing it out we um exit with zero, because it's successful all right. So that is what get status does um so you can see that kit is a little bit duplicative, not in a way that is like important. You know it's. That was all those were all very cheap actions.

A

That's not a big deal that get kept reading the same files over and over again a little odd, but I'm sure there's a good reason for it that I don't understand. Okay. um So, let's now we've done that let's go ahead and commit the.

B

A

um So we'll just ask our standard s, trace, preamble and then git commit with a message.

A

Okay, okay, so let's take a look at that trace.

A

All right, it's just like last time we exec ve loader, shared libraries, we're just going to skip right by that this time we read our git configs, just like last time start saying some symbol handles.

A

Once again, we lock the index.

A

Okay, so here you can see, we've created a new file here, git objects, e0 and then it's just a temp name or actually I'm sorry, yeah, oh yeah. Okay, we try to create it, but the directory doesn't exist. So then we make the directory e0 and then we create the file using this okra out flag here.

A

So we've got a new empty file. Here we allocate a little bit of memory. Then we write in the new object into the temp file that we've got allocate a bit more.

A

Okay, then, we can close that, and here we create a hard link to this same file.

A

So the current path is here and here's some new path, so we're creating the actual name of the file as opposed to this temporary name previously. So this is the final name of the file, one with the hash and so forth. Now that we've created the hard link, we can unlink or delete the original temp file, and we just have that. You know this actual get object. File is now the only thing left.

A

Okay, um we seek back to the beginning of the index lock file, so lseq just takes your your position within a file to an arbitrary location, so in this case we're seeking the zero so the beginning of the file. So if we wanted to go back to the beginning of it and read okay yeah here we are here, we actually write out to the lock file. um Something compressed uh looks like directory tree, but I don't entirely know what's being written there. Okay, we've done that.

A

We close that um and then here we can rename index.lock to the new index file. So we replace the index.

A

So, as you recall, and when we did the git status, we created index.lock, but because we didn't actually change the index at all. We just deleted the index log file. In this case we've created a new index.lock and then by using rename this atomically we'll we'll do the change. So you don't have a concern. If someone else changing it up for under you, you don't have any race conditions. So this way we can make sure that the uh the new index is definitely the one that we just wrote.

A

Okay um and then we see if there are any git hooks in this case we haven't created any so that just we continue on. We check the time get our time zone um see if there are any pre-commit hooks there or not.

A

um We see if there's a commit edit message file. There is not we just passed in our argument from the command line.

A

We open up our head.

A

We read the current ref for master.

A

Let me check if there are any pack drafts and so on, read head again check for pack graphs again.

A

Okay- and I believe no, this is not the object we created just now. This is the old object. Okay, so we re open that up, read it in close it and unmap. It again check out this file as well.

A

Okay, and then we write into the alright mr created that.

A

Do we create that.

A

Okay, yeah, we did read it, we opened it.

A

We didn't pass yeah. I guess that already existed interesting, okay, um unless it was yeah okay. Here we are here's where we created it all right, so we created a commit edit message over there all right here we open that file. Up again, we write in the message that we put from the terminal close that out.

A

Open it and read it again now that we've gotten it saved to the disk.

A

What are we doing here? Opening existing object?

A

This was the this easier object, is the one we just created earlier in the commit. So it's presumably the commit object.

A

We can check after this, if that's the.

A

Case we can just check right now.

A

B

A

That is a blob actually, so that's the blob, not the committed object. Okay, I would guess that this is the object. Let's see.

A

Shoot I just forgot that was a 4-2 yeah 14., okay,.

A

Okay and yeah: this is the commit object. Yep, okay,.

A

So yeah git cap valve, we can see what the actual contents of this are, um although when we look in the s trace, this is um all been z, libbed into binary format. So it's not even.

B

Readable there.

A

But that's that's the contents that as git understands it. Okay.

A

So now we see if our commit object, exists, read it or create the temp file, just like we saw with the blob earlier uh that fails, because this for two directory doesn't exist, so we make the 4-2 directory. Then we try creating it again success.

A

uh We write out to the temp object just like before we close the temp object and then create a hard link to the actual commit file and then unlink the temp object.

A

Okay, read head again: we create a head.lock file here. Once again we have the o exclusive flag to make sure that no one else is locked head.

A

Okay, we also lock the master ref.

A

And we're opening up here commit object again a couple times. I've read that in memory, okay,.

B

A

We write the new hash, the commit that we just looked at here for the master lock, and then we write to the log here's the new commit that we just added.

A

uh Let's see have we already written the head, I just missed that somewhere in everybody in the head. Oh yeah, here we know that's her reading to it.

A

Okay, okay and then okay, now, let's rename the master block master. Like I mentioned earlier that works atomically, uh we unlink all the well. If these files had existed for the uh for this action, we don't link them. So we just do that to be safe.

A

Here we are creating a child process, so we're using clone to create a new process. So here you can see we're kind of intermixing these processes. So we start with two two. Three, two six is the parent two, two three, two seven as the child. um You can see this sick child here.

A

um If you see a clone underscore thread, then you know it's a thread. Otherwise it's a child. It's the easy way to tell with these um okay. So here we create the child, and then you can see that immediately. This I mentioned earlier that we start doing a ton of rtc actions with this child process. We're just, I think, we're just inheriting the single handlers about the parent process, so we go in and set all those right at the start.

A

So that's a really easy way to tell that a new process has been forked or cloned because yeah, you see it just this wall of rtc action, okay and then you can see that with this 22327 is now ready to actually start executing its binary, so it execs user local, then exec core git, which, with errors, get gc-auto.

A

Let's see, I'm.

A

A

Yeah okay, um so if you actually look at this file, it's.

A

A

Yeah, so it's not a sim link, it's actually a separate binary, but it's identical to user local bin git. So this is these two are the same thing just in different locations for some reason.

A

Okay, um so we call git gc.

A

Just to clean things up and once again you can see: we've read in our shared libraries blah blah blah. We don't care about that at this point, we're reading in the git repo and git configs to start pretty standard.

A

um It's like the parent directory, okay, yeah, so the parent process you can see we didn't actually have any events from them up until um the child process exits and that's common you'll, also see it where the parent continues to work and is not waiting on the child. But in this case it is so two to three two six is is just sitting there waiting for the g g to finish.

A

In this case, I don't think gc really has anything to do because there's do we even have like a pac file. Yet no, I don't think we do yeah and there's barely any objects, so there's nothing to gc at this point, so the git gc exits basically immediately having done almost no work with success, and then here we can see that it was waiting. So if we look at the previous event for 22326.

A

Yeah, okay, you can see hey I'm waiting on pid22327 here and then it just sits. There waits until 2 2, three two seven is exited and it gets a sig child as well saying: hey. Your child process has exited wake up. Okay, so so it wakes up at this point.

A

uh It looks for head, it opens head, it reads: it closes. It reads, master again having just written to that a minute ago.

A

uh Looks like it's just reading in the repo at this point.

A

Yeah, okay, so it reads everything and then it writes out to the console. One file changed. One insertion.

A

Tries to open this but doesn't exist, I guess there's nothing dust and then exit was here, and so that is what a git commit looks like, and I get to see it doesn't do anything um okay, great well, thanks for watching uh next time, we'll get into s, tracing unicorn and puma, and looking at what uh you know, the gitlab rails. Application is doing when the typical request comes in all right. Thanks.

A