 projection like four times, so it's going to be a great time for it to break. So I'm Valerie Arora. I'm here to tell you how iFenix fixed Unix A time, which is a 40-year-old file systems problem using 10 lines of code approximately, and feminism. So I wanted to start this talk out on the right tone, so this is a picture of me drinking a beer while driving a tractor in 2006 while I was working on this code. I've done a few other things since then. I was a file systems developer for about a decade. I'm now the founder and principal consultant at Frameshift Consulting where I do diversity and inclusion in technology. So the first thing you need to know is that every Unix file has three useful timestamps. So the first one is the access time, which is the last time that the file was read, also known as the A time. These little abbreviations don't really make sense, but let's go with them. The M time is the last time the file data was written, or the modified time. And the C time is the last time the file metadata was changed, or the change time. Thank you NSA for telling us all what metadata is. Thank you BFF for making this great logo. So these timestamps are all part of something called the iNode, which is metadata. Thank you, NSA. And it's written to the disk along with the rest of the file data or to the storage. So as an example of how timestamps are used is if you have a mail reader, which reads mail stored in a file and a mail receiving program like send mail that appends new mail to the end of that file, you can use the timestamps to figure out if there's new mail. So if the access time, the A time or the last read time is greater than the or more recent than the modified time, then you know you've already checked it since the last time somebody put mail in the mailbox. If the A time is less than the M time, you know you have new mail, hooray. Okay, so the next thing you need to know to understand Unix A time is that there's a huge difference between memory SSD and disk access times. So memory is about 100 nanoseconds to access, SSD is about 16,000 nanoseconds, disk is about 3 million nanoseconds. So this is a huge difference, right? So if you want to talk to memory, that's like going to the corner store. If you want to talk to SSD, that's like walking from the Empire State Building to the New York Trade Center, the World Trade Center. If you want to go to disk, that's like walking from New York City to Washington DC and back again, right? So you don't want to go to disk or you don't want to go to storage, but disk especially. The great thing about reads is that they can often be cached in memory, so you don't have to go to the SSD or the disk. The problem with writes is that they always have to go to SSD or disk eventually. There's a bunch of well-actualies in here about if they overlap or if you rewrite them or merge them together. But really, the thing you need to remember is that the first rule of file system club, avoid writes. So the problem with Unix A time is that it turns every read into a write because you have to update the last read timestamp. This is a write. Who thought of that? This is a terrible idea. It's like if you wanted to go to the corner store and you ended up walking to Washington DC and back again, right? Horrible idea. It's been there since 1969. All right, so here's what Ingo Mollner had to say about A time updates, which I thought was great and perfect. A time updates are by far the biggest IO deficiency, performance deficiency that Linux has today. Getting rid of A time updates would give us more everyday Linux performance than all the page cache speed ups of the past 10 years combined. That's pretty specific. Maybe we should fix this Unix A time thing, right? So here's the first non feminist solution, which is no one gets A time, no A time for anyone. So you could turn off the A time updates on an entire file system or you could do it on a per FD basis, but who does that? Nobody does that. So the first thing you would do after you installed Linux, if you were a power user or you had to do something with high performance, you would immediately go and turn A time off on all of your file systems by using the now option. But you couldn't do it by default because it would break a whole lot of programs that depended on A time, right? So you had all of the power users turning off their A time, haha, I'm hacking at CFS tab, but everyone else had this really slow system. So as an example of a program that this would break is this mail reader, right? A time greater than M time, no mail, A time less than M time, there's new mail. If you have no A time updates, you have no idea, there's never any mail. Why doesn't anyone love me, right? So whenever you would complain about this though, a bunch of file systems programmers would sneeringly explain to you how you needed to rewrite your application, not to use A time, right? And this is true, every single application that used A time could be rewritten to not use A time. We could also rewrite every application to not use file systems, or we could just throw away our computers and use rocks, right? Like what the heck? I'm a file systems developer, I want to make stuff for people to use. Okay, so here's the next, there are a bunch of other non-feminist solutions that people propose, and they all seem to center the code and the file system structures. So one of the examples was people said, okay, let's just keep a big list of I nodes in memory that have updated A times that we should run it, we should write out eventually, and let's wait to the best possible moment, which is when the system is running out of memory, and then we'll write them all out to disk at once. It'll be great. I mean, really all storage likes small random writes, and people with that one got shot down when people did calculations and were like, yes, you could keep storage busy for several minutes doing this. It's a terrible idea. So in general, I felt like there were a bunch of solutions in this vein, and I felt like that they were missing the forest, which in this case is what users actually wanted to do with their file system for the trees, which were the file system data structures and the code. I find this pretty frustrating. So here's how I fixed A time the feminist way. Remember at this point, it's 2006, it's been 37 years that people have been trying to fix this problem. So the first thing I did is I went to a place that had psychological safety. In 2006, this was Linux chicks. This is a group for women in Linux, and some of our rules were be polite and be helpful. And it was amazing because we could have technical discussions without people sneering at each other for their weak use of A time. So the next thing I did is I actually listened to people. One of my friends, her laptop was going slowly, I gave her the standard advice, oh, turn off A time, of course. When she told me that her mail reader didn't work, I didn't sneer at her and tell her to reconfigure it to use checksums or timestamps or mailder or whatever the solution was that people usually gave her gave people. I thought, gee, that seems like a reasonable thing to want to be able to do in your application. The next thing I did is I centered the person. I said, well, what is it that my friend is actually trying to find out with her mail reader? I thought about it, and what she really wanted to know was not the exact second that this file had last been read. Time stamps are usually seconds since the Unix Epic in 1970. What she actually wanted to know was, was the last read before or after the last try? What was the A time relative to the M time? Because if it's after the M time, there's no mail. If it's before it, there's new mail. It doesn't matter exactly what the seconds are. So this helped me come up with a solution I called relative A time. And it just asked this question of what is the current A time on the file as the time it was last read, greater than or less than the current right time? If it's after the current right time, don't bother updating it. Don't send that right to disk. We don't really need to know that information. So in the mail reader example, if the A time is greater than M time already, there's no new mail. If I go and read that file, there's still no new mail. It doesn't matter how many times you check your inbox, it's not going to magically produce mail, like spontaneous generation. So you don't have to write to disk. The best part of this, I'm so proud of this. It was so simple, I refused to patent it. Relative A time was about 10 lines of code in the kernel. There was a little bit more code in the file system utility tools to create the mount option. But this is basically it. This is what got checked in in 2009. Yes, it took three years. But it asks, is the current M time younger than A time? If so, update the A time. Or is the current C time, remember, we've been ignoring the metadata, hey, I had to say. But if the metadata change you want to care about, you want to update the A time as well. And then this is one thing I didn't talk about yet. If the old A time, the old last read time is more than 24 hours old, go ahead and update the A time again. Just so that there's certain programs that would check to see if a file had been used in a while and deleted if it hadn't been. So like in slash temp, there's a bunch of temporary files that will go away unless you have this one extra line of code. And otherwise, skip the A time update. So yeah, in summary, here's how feminism helped me fix Unix A time. I joined a safer space to talk about technical problems. I listened instead of mocking or shaming. I centered the person instead of the file system code. And I answered the real question. And that is how feminism helped me save billions of disc rights over the last seven years. I really think I'm really proud of the solution of all the work I did in my 10 years of working on file systems. It's what I like the most. And I feel like becoming a better feminist helped me become a better file systems developer. And I'm still seeing this happening today, people proposing solutions that are completely myopically focused on the internals of the file system, rather than the sort of thing that people actually want to do with their file system. So these days, I teach an ally skills workshop in part, workshops in part because I learned all of this, how important all of this was to building better products. So I teach people how to create safer spaces. I teach them how to listen. This is amazing. People come to me after the workshop months later and like, my God, everyone is saying these interesting things around me all of the time. Do you know what my daughters say? Wow. I teach people how to center the person and a bunch more stuff. And sometimes there's lightning. No, that never happens in the workshop. Plus, I'm finally writing a book on ally skills because I want to get it out to more people. So you can go to my website and sign up for my loose letter. Or you can follow me on Twitter at Frameshift LLC. Thank you very much.