In crowd today, what's going on? Guess I'm just getting more and more boring as the semester goes on. That's all right. That's how it feels up here too. All right, so today we're going to talk about caching. So we've discussed how file systems provide core file functionalities. So translating path names to iNodes, finding stuff based on name, and then finding disk blocks based on an offset into the file. So one of the core things that we do to try to make file systems, so the disk is really slow. I mean, the disk is sort of out in Haley's Comet land slow. If Mercury is registers and the Earth is main memory, well, main memory is probably like Pluto, then the disk is way off and like some other galaxy. So we try to make the disk look fast. And this is true even for modern disk technologies. I mean, flash is faster in many ways than spinning disks, but still way, way, way slower than main memory, way slower than close cores that are close to the chip, like the L1 cache. So like caches that are close to the chip and obviously way, way, way slower than registers. So we're going to try to make a slow thing look fast and we're going to do that in a typical way. And then we'll talk if we have some time at the end of the day about journaling because the tricky thing with using memory as a cache is that it doesn't always interact all that well with our attempts to make sure that the file system stays in a consistent state. Because the more stuff we hold in memory, the fewer things go to disk, and if the system crashes suddenly, that can leave the disk in a place where it's difficult to recover. So we'll talk about how we do that. Okay, so just to understand what's going on for the next few days. So today we're going to try to do caching consistency along with journaling. We'll see how far we get. Friday, if we make progress today, we'll do a couple of papers on sort of classic file system designs, FFS, which is really crufty and ancient by now, but which introduced a lot of sort of core file system features. And then LFS, which was a really sort of controversial paper in the file system community and introduced a radically new design for file systems. So when we get that done on Friday, on Monday we'll talk about RAID. So for the RAID class, what I'm going to ask you guys to do is actually look through a research paper. I know this is a little scary, but it's like a classic paper. This is just one of the classic papers. I don't know how many times it's been cited, but it's probably in the gazillions by now. And then in class we'll talk a little bit about how RAID actually works. We'll go through the paper together. Okay, so what's our classic approach to making a slow thing fast? So the disk is slow, right? The disk is, the nice thing about the disk is that it's persistent. When I put data there, data survives from reboot to reboot. It survives when the power is disabled, but disks are also slow. Again, this includes today's flash drive. So what's our canonical technique for making a slow thing fast? Look faster. Caching, right?  What is the small, fast thing I'm going to use? So when we did this for memory translation, what was the small, fast thing that we used? The TOB. So the TOB acts as a cache of a recently used address translations that means that I don't have to ask the kernel every time I need to translate a virtual address to a physical address. So that makes things a lot faster. In this case, what is the fast thing that we're going to use? What is the cache here? What's the thing we're going to use as a cache? What's the slow thing? The slow thing is the disk. So what's the cache? Memory. Memory, yeah, memory of various kinds. So I also, to make sure that you understand how complicated this actually is. Does anyone ever bought a disk? Ever purchased a disk? Never. Wow, well you have some exciting experiences ahead of you in your life. Like I just bought two disks today. One of the things, really, no one's ever bought a disk? Okay, good.  I get it, okay. You guys are like the disk. I sent a command. I gotta wait a while for Data to come back. Okay, so I'm gonna make you faster. One of the things that you do when you create disks today, has anyone ever looked at a disk, the specifications carefully? What do disks typically have themselves? A cache. So big drives that you buy have their own internal caches. So while the disk is on, the disk has its own little memory cache. And sometimes those caches can be quite large. So it's actually caching data internally. How that cache interacts with the rest of the system is complicated and not so like we're gonna talk too much about. But anyway, remember, computer systems just a series of caches. So there's even one on the disk itself. So we're gonna use a cache. The thing that we use to cache stuff is memory. Now, so this is interesting though, right? Because we're using memory. What else do we use memory for? RAM, what else do we use RAM for? I mean this is kind of weird, right? What else do we use the TLB for? The TLB is to use the cache address translations. And what else? Anything else? No, the TLB is exclusively, the TLB is, I've said something wrong, I guess. The TLB is exclusively for caching these translations. What else do we use memory for? Come on, you gotta give me something today. I know it's something that got cold again. It's gonna get warmer, just wait, okay? Come on, we'll get there, it's gonna be May. The trend line is clear, right? There might be some local. What else do we use memory for? Like memory, remember all the stuff we talked about in the last couple of weeks? Like process pages, kernel data structures, the heap for processes, code the processes are running, like all sorts of other stuff. So the modern systems have this interesting balancing act to do where they have memory and they wanna put that memory to use, but there's two competing uses for the memory, among others, actually, but these are probably the two primary ones. One is to use for memory stuff, like process pages, parts that would be part, things that would be in my address space, and then the other use is as a cache for the file system.  You come back later and the system is sluggish for a couple of minutes. One of the reasons that sometimes happens is that over time, because you haven't been using it and processes haven't been running, the operating system has decided to take all the memory or a lot of the memory on the system and convert it into a cache for the file system because there's a lot of ongoing file activity. So when you come back and start using the machine again, even though there's a lot of memory, it doesn't feel like there's a lot of memory for a minute until the machine sort of catches up with the fact that, oh, okay, there's programs running again and it starts to move the needle in the other direction. So at runtime, Linux, and I suspect Windows now are making decisions about how much memory should I use to cache file system contents and how much memory should I use to cache process pages. And Linux, okay, so let's talk about what happened. So let's say I have a big buffer cache. So the memory that we use to cache file system contents is something we refer to as the buffer cache. This is a cache for the file system. When the file system cache gets really big and I don't have a lot left in main memory to use for other stuff, what happens? What's that? Well, I'm gonna swap more quickly. What is that gonna cause to happen? So file accesses get really fast because a lot of file accesses is hidden in the cache, assuming that I have a large enough cache, but programs suffer because programs take higher page fault rates. So this is essentially like running the same set of programs and a machine that has a smaller amount of main memory. The only difference is all the file operations that the programs are doing get faster. On the other hand, what happens if I have a really small buffer cache and a lot of main memory? Yeah, so in this case what happens is that processes run pretty well, page fault rates go down, but every time I need to use a file, those accesses are really slow. And obviously getting the balance here is really tricky. Linux has this, maybe this is gone in newer versions, but at least on many versions of old versions of Linux, they had this parameter called swappiness, which I always thought is a fantastic parameter because like, I don't know. I mean, Linux has very few parameters, but this is a number between zero and one that essentially is a hint to Linux to tell it how much it should prefer one use of memory, that being for process pages and other address-based contents versus the other use of memory, that being for the buffer cache. Linux still reserves the right to make its own decisions about this, but this is sort of a parameter that tells it how aggressive it should be about trimming process pages so it can make more room for the file buffer cache. All right, any questions about this? Does this make sense? I know we haven't really talked about how the buffer cache works yet, but that's what we're gonna start doing. But you can kind of think about it, you know? Yeah? It's zero through one, it's like 0.0 through 1.0. It's a floating point number for some reason. Probably fixed point actually, but what was your question? Yeah? No, that's the point. Like you can't stop it from using memory as a cache, and you clearly can't stop it from using memory to cache address-based contents because you wouldn't be able to run anything, right? So this is just a parameter that kind of gives it a hint about where that balance should be, right? And specifically, I think what it affects is how quickly, so remember we talked about over time when a process hasn't run for a while, the kernel will actually go to the process and try to pull pages back, right? It'll say, okay, I'm trimming your pages to make room for other stuff. Swapping is, if I remember correctly, controls how aggressive the kernel is about doing that. Now, any pages that I recover that way, assuming there's file system activity can be reused for the buffer cache. So again, if you run something like some of my students have been doing some data processing on their machines, so they're processing like a couple terabytes worth of data, if you run really, really heavy file system workloads, the best thing to do at that point, as long as no one else is trying to do anything, is to use as much memory for a cache as possible, right? As long as you have a reasonable page fault rate for what's left. But what happens is after you do that for a few hours or overnight, the system could get very, very sluggish until you start moving the balance the other way. That make sense? Cool. All right, so now let's talk about where this cache goes. So caches always have to be somewhere, right?  But when we talk about where to put the file system cache, there's sort of an interesting design question here that controls what the cache sees and doesn't see. Okay, so here's a design, well okay, so this is sort of a diagram that's actually taken from OS 161. So, OS 161 like other operating systems, remember the file system is fairly decoupled from the operating system. I can have an operating system that is using multiple file systems at once. I was having a conversation with somebody after class and they were talking about, well how does this work like when I boot a recovery CD, right? If you boot Windows off a recovery CD, that can clearly read the disk.  So if I have an on-disk data structure in a part of the disk that corresponds to an EXT4 file system, as long as I have software that understands how to read and write that file system, I can modify it, I can take that disk out, I can sort it into another computer and I can modify the files on that computer, right? As long as I have the software required to interpret that file system, that's how thumb drives work, right? Thumb drives typically have a file system that's called FAT32, it's a really terrible crappy file system but it's been around for a long time and people use it because it's very portable. So I can take a thumb drive that has FAT32 on it, I can second it to a Windows machine, I can second it to a Linux machine, I can second it to a PC, all of those machines have software on them that allows them to interpret that on-disk data structure, make changes to it, find files and stuff like that. Okay, but one of the things that operate systems are required to do to support all of these different file systems is build these translation layers. So the VFS layer, I mean you guys, does anyone really have an idea about how VFS works? Who wants to be brave and raise their hand? Okay, at least, so when you guys implemented read and write, right? There was something kind of weird about what you had to do there, what was that? How did your read and write system calls? Hopefully I'm not exposing these solutions that bite asking this question, right? I mean, I don't think this is that particular, I would have told you this in Office Hour, so what are the corresponding calls that read and write make in OS 161 to the VFS layer? I mean, basically read and write, collect a little bit of information and then make a call to what? VOP Read. VOP Read, is VOP Read a function? No, it's a macro. Does anyone know what it does? Yeah. Yes, ooh, see function pointers. This is like a, anyway, does anyone know what a see function pointer is? Does anyone have done a programming with see function pointers? Yeah, you don't need see plus plus, man. You can do everything in see plus plus with see function pointers and a huge amount of bravery and stupidity, okay? So this is like as close to see gets as see gets to object orientation, right? Namely, I can have a function pointer and many of trial they work to be honest with you, but I think it, I will stop it. I think it points to a place in memory and I can make function calls to that. So the reason, so given this diagram, why do I use a function pointer to do these reads and writes? What is this to allow the view, what's actually happening here? Yeah, exactly. So this, again, this is as close as see gets to object orientation. So the VFS layer defines an interface that the file systems that implement that are allowed to run on OS 161 are required to implement. When you make a call through that macro, what happens in a simplified form is that the macro uses the V node to figure out what kind of file system this file has been mounted on and then it passes the call down to the right file system. So up until this point, you guys have been using the MUFS file system which allows you to access files on your local drive. Had we made you do assignment four, you guys are doing pretty well this year so it's not too late, maybe we'll add that toward the end of the year. You would have had a chance to work with the simple file system which is implemented entirely inside OS 161 and uses a virtual disk. But this is, so this is the idea. Essentially, again, remember, everything comes back to interfaces. The VFS file system imprides this interface to implement a file system on OS 161 you have to implement most or all of that interface, right? You certainly have to implement things like read and write and stuff like that. Does this make sense? So this is how this is working internally. So when you make the VOP read or VOP write call, depending on the information that's stored in the V node that you pass in, it could be calling a SFS function that does the read or it could be calling an MUFS function that does the read and I can add arbitrarily large number of additional file system implementations as long as they conform to the interface that the VFS layer is provided. Okay, we're never gonna get through today's lecture because I just talked too much about that. Okay, so here's one option about where to put the buffer cache. So in this case, the buffer cache sits directly below the VFS layer. Remember, I have this VFS path through layer that aggregates all the calls to the different underlying file systems and so this represents what we call in systems a narrow waste. This is one place where I can put a cache and the cache then sees a lot of the operations that it needs to see in order to do things. So at this and the other place I can put it is down here at the bottom. So all of the file systems, this is another place where these file systems come together, all the file systems on the system that I care about caching data for, there might be network-based file systems that have their own issues. But there's two pieces of commonality to all these pieces of file system software. The first one is they have to support this VFS interface. The second one is they read and write blocks to a disk. Does that make sense? What happens in the middle is completely specific to each file system but all the file systems support a common set of operations listed up here and are implemented by modifying disk blocks. So they use the disk block interface. So there are two options where I can put the buffer cache. I can put it on the VFS underneath VFS where it has to support that interface or down here. Okay, so if I put it underneath the VFS layer, then the buffer cache has to support operations. So the other thing to think about when you implement a cache is what are the operations the cache has to support? So what's gonna happen here is that before I pass these calls down to the corresponding file system software, I'm going to allow the buffer cache to see the call and potentially return cached information. Does that make sense? So some of those calls are not gonna make it down to the file system. They're gonna hit the buffer cache and return immediately because the buffer cache is gonna say, hey, I've got the contents of that file in memory right here, I don't need the file system software to go to disk. So if I put the buffer cache to the top, the buffer cache can actually now cache entire files and directories. That's all it sees. This is interesting in a vocation. And the interface I have to support is the same as the VFS layer. So I have to see or at least part of the VFS layer. Maybe I don't support open, maybe I don't support close, but probably read and write. Those are the heavy hitters. Those are the areas where actually I'm gonna have some win by returning data from the cache, yeah. Yeah, I mean, you probably need a configuration parameter so when you mount a file system, it can avoid these caches, right? Probably the other way to do this is to actually have the cache here on a file system specific way. That's another way to do it, right? So rather than putting it right here, I put it at the very beginning of the file system's own operations, right? That's another way to do it, yeah. There are some file systems that can't be cached either because they're not real file systems. They have semantics that the cache doesn't understand or whatever. Yeah, so that's a good point. Okay, questions. Did someone have, I heard of hearing things again. Okay, so let's give an example of how this would work. So opens, I need to pass down to the underlying file system. Reads, I look for the contents of the read in the cache. So I have a file system, I have an inode, and I have a spot in the file, and that should be enough information to identify the cache block in the cache if it exists and return that if I have it. If not, then I pass it down to the underlying file system. Write, if the file isn't in the buffer cache, I can pass the write down. And I also wanna load things into the buffer cache at this point. So file system caches are effective at absorbing both read and write traffic. But when I see a write to a data block that's not in the cache, it's frequently used for the hoist that data block into the cache so that future writes hit the cache. Does that make sense? So when I see a write, I read the block from disk, make the modifications in memory, and then write it back immediately or wait. And we'll talk about the policies that determine how long I wait to write things. Close, I can flush things from the cache when files are closed. Maybe I do, maybe I don't if I need space. Okay, this doesn't make sense. Okay, I don't know why the slides are being weird. So the nice thing about this is that this file system cache has more semantic information about what's going on. When we get down to the next alternative, keep this in mind. So I see a read as a read, not just as a random group of data blocks that are being accessed. There are a couple of interesting cons here. So one problem with this approach is that there's a lot of information. Remember all that stuff on disks that's not file contents? The inodes, data structures, stuff like that. We talked a few classes ago about how some of that stuff might be really, really great candidates for caching. Inodes, for example. Inodes get modified all the time, particularly the root inode. Why does the root inode get read so much? Constantly, yeah. Every path name starts at the root. So the root and probably the next level of directories under the root, those inodes get read and those directory files get read constantly. So I want those in the cache. In fact, it probably makes sense to just cache those immediately as soon as the file system boots. They're also very, very rarely modified. I mean, when's the last time you added a directory to root? You can, by the way. You can put your own stuff in there if you want to. You're not gonna get in trouble. Unless you're trying to do it on a machine that's not yours. Anyway, so yeah. So that's stuff I want in the cache. And in this approach, I can't cache that stuff because I never see that information. Remember, when I call open, there's all sorts of metadata that the file system is using to translate the path to the contents of, to the inode. But I never see any of that if I'm caching stuff at the top. Because all that activity goes on between the file system and the disk itself using the disk block interface. So this is the problem with this. There's another issue which is that there are certain consistency guarantees that are hard to provide up here. Because of the, because of the way, the little, because of the calls that I'm actually seeing. Okay. So let's try, let's think about the other option. So the other place to put the cache is below the file system. So what do I cache here? I know I should have pulled the diagram back. If I put it below the file system, what are the objects in the cache? Yeah. So I can cache anything that's beyond the disk, but what are the objects in the cache? What do I name them? They're disk blocks. So above the file system, I have to think about files, names, locations. Below the file system, it's just disk blocks. If I see a disk block accessed, I pull them into the cache and I name it based on the disk block where it came from. At some level, this is a little bit simpler. What's the buffer cache interface? Above the file system, I had to think about supporting open, closed, read, write, whatever, what do I support here? Read block, write block, that's it. There's no open, there's no close. So at some level, I've lost information about what's going on. So rather than understanding that a series of disk accesses corresponds to a read, all I see is a bunch of read blocks and write blocks. I have no idea what caused them, okay? The nice thing about this, as Ashish pointed out, is I can cache everything here. Everything that's on disk can be cached. That includes all the file system metadata and a lot of that metadata is really valuable to cache. And this is one of the reasons why it's done this way frequently. And so again, I mean, it also allows file systems to see operations. So even if I'm gonna cache the result of a read, the file system still sees that the read took place because the operation hit the file system implementation first before it got to the cache. And that's good in certain cases. That gives file systems some visibility that they need to provide certain consistency guarantees, which is good. The cons are that I've lost information at this point. So at this point, some of the semantics of things are missing. And this is a really common trade-off. So again, I mean, why are we talking about file systems? File systems are boring. They're not evolving very rapidly. But this trade-off is the same when we talk about web API requests in a data center. When the request comes in, I have a lot of semantic information about the request and what it's trying to do. And by the time it gets down to sending packets between two machines or doing local disk operations, it's gone. I mean, every time you load mail from Gmail, that corresponds to some number of network operations and disk operations and other things that go on in Google's data centers. But as that request goes down the stack, information is being lost along the way. I know the most at the top and I know the least at the bottom. Okay. And this is what modern operating systems do. This is for a variety of reasons, partly because it's so valuable to cache metadata. Really want to cache metadata. That stuff, there's a huge win to caching inodes and other on disk data structures. Okay. Oh, we're not gonna do review. Yeah, sorry. Okay. How did this get in here? Okay. All right. Okay, here we go. All right, any questions about this stuff before you go on? Okay, so I'll talk about cache. So now, okay, so this seems simple. It used to, yeah, I don't know. That's one, I don't really miss assignment for that much, but I do miss the buffer cache part of assignment for. We used to have you guys implement a buffer cache for the simple file system. The cool thing about it is, has anyone had that experience with an algorithm where you implement an algorithm and it makes something go much faster than it did before?  That's kind of cool, right? Buffer, one person has had that experience? Okay, good, thank you. About to say, we need to change how we teach algorithms. Buffer caches are kind of the same way, right? Like, especially because OS 161 disk is so slow, so it's like, whoa, that thing suddenly really worked. Yeah, caching is good, caching works. And this is a good place where you can see, you can really see the effect of it. All right, let's talk about consistency. So the first thing to realize is that there's a sort of a direct trade-off between performance and consistency when it comes to file systems. How does caching, how does memory caching cause consistency problems? It's a basic level. Do any right analysis in store is a cache, but you haven't been telling it on the distance and sometimes it takes a lot of time before you decide to write it on the list. Right, so caching, particularly caching writes. Can caching reads cause consistency problems? It's hard to make an argument it can, right? I'm sure there's some weird case in which it can, but reads are pretty safe. So caching reads, allowing reads to return from memory caches is usually a pretty easy win. Writes, on the other hand, are problematic. When I hold a right in the cache, so when a right hits the cache and then doesn't go to disk immediately, what happens is there's a period of time in which the contents of memory and the contents of the disk are out of sync. So memory has information that hasn't made its way to disk yet. So why is this a problem? Yeah, yeah, so if there's a power outage, someone trips over a cable or something crashes, machine reboots, whatever, I mean on a reboot you're gonna flush these caches, but if there's some sort of unexpected event that causes the data in memory never to make its way to disk, then it's possible that the disk is corrupted in some way. And so the big goal here is not to make, you know, I mean it's easy, in certain cases I can just make everything go to disk, but the problem, the goal here is not necessarily to make this problem go away entirely because we want to hold writes in the cache, that improves performance a great amount. The goal here for modern file systems is usually to make sure that even if there's some data loss, the file systems data structures are consistent. So for example, it's okay to lose a few of the modifications you made to your OS 161 source code. It's not okay to lose inodes, right? Or to lose a whole directory, or to have bitmap, or have bitmaps that get corrupt so that I think that some of the file system is in use or have files vanish, right? Like if I'm in the middle of moving a file from one place to another, if the system crashes, it's okay for it to be in the first location, it's okay for it to be in the second location. It's probably preferable to be in both locations, although that's a little weird, right? And we might need to fix that, but it's not okay for it to be gone, right? It shouldn't vanish. So these are the kind of consistency problems that we try to prevent. The other thing, and the thing that makes this difficult, which I forgot to mention is that, remember going back to talking about reads and writes and other types of file operations, these touch a lot of blocks. You know, if reads and writes were typically confined to modifying one block on the disk, that might be okay, but I have to modify a bunch of blocks. And so now, maybe when the system crashes, some of those modifications would be written to disk and some haven't. And making sure that things go out to disk and consistent groups is another thing that we're trying to do here. So that either the entire operation happens or didn't happen, but it doesn't kind of happen. Like I'm not halfway in between. So yeah, we talked about this before. So in this process, if I fail here, for example, then I have a case where I have data blocks that are marked as in use that are actually not linked to any file. And so the capacity of my disk went down a little bit. Okay, so as I just pointed out, if anything that modifies multiple blocks can potentially leave the system in an inconsistent state, if a crash occurs, and not all of the modifications make their way to disk. And this can happen even without caches, right?  So on old disks, it was like change block one, run over here, change block two, run over here, change block three, oops, crash. And suddenly I am only made three of the six modifications that I want to make. So this can happen even without a cache. I don't want to make caches the sole culprit here. But caching exacerbates the situation by increasing the time span. So think about there being like a window of time where the failure has to happen. So if I fail at just the wrong moment, I can always cause some sort of consistency problem. But as I start to hold objects in the cache and delay modifications to disk, I lengthen the period of time. So if I hold things in the cache for long, long periods of time, there's long intervals where the disk is in in sync. And if I'm not careful about how I do that, any crash within that interval will cause a problem. Okay, do you guys want to go over this? We went over this before. This is sort of what can happen in each one of these cases if there's a failure. So if I, so this is a write, right? So I have to allocate, this is a write to a new operation, a new file. So I have to find an inode. If I crash, and this doesn't make it to disk, then there's an inode that's incorrectly marked in use, which means I'm down one inode. If I crash without updating, after updating the data blocks, I have some dangling data blocks. This is a fun one. This is how stuff ends up in lost and found, right? So I have an inode that points to data blocks, but that inode actually hasn't been linked into a directory yet. So I have a file that exists nowhere, right? So that's not good. And then if I don't write the data blocks, I have some data loss, right? But again, from the perspective of the file system, I care a lot more about consistency than I do about data loss. Okay, any questions? Yeah. If you do like check this below. Yeah, I mean this is what FS, has anyone ever run FSCK before? Yeah, so there are programs that can take a file system. Remember, this is just an on-disk data structure. As long as I understand the semantics of it, I can check it for consistency. So for example, I can go through all the directories on the system. Let's say that I want to enumerate every inode that should be in use. I basically go through all the directories and I find all the inodes that get linked to. And so now I have this set of inodes that I know are in use. And I can compare that with the set of inodes that are marked in use in the inode bitmaps, right? Now, this operation, FSCK. I'm going through the entire disk, doing all these consistency checks. Does this sound like something that's fast? Yeah, so another goal of sort of modern file system designs was, look, stuff's gonna fail. Who knows why? Doesn't matter. The goal here is not to never fail because that's impossible. The goal is to recover quickly after failures. So again, let's say you're working in Amazon and their entire data center goes down, okay?  Like someone just flipped the data center off switch, right? So you just go turn it on again, okay? I'm cool. That sounds good, right? Like the data center's on again, except if I have to run FSCK on every machine, don't worry, it's gonna be on CNN, right? At that point, days go by, you know? So outages are not the issue, right? Outages that can be recovered from quickly. Imagine that your system could reboot instantaneously. Would you notice blue screens? Be like a little flicker, like blue screen, whoop, there it is again, right? Who cares? So coming up quickly after failures is really important. That kind of thing that we just talked about where I have to enumerate an entire disk and do these huge holistic consistency checks, those things are terrible. They take forever, they're slow. There are they good? Yeah, I mean I can do a really, really hard check of the entire disk that way. Do I wanna do that when the system already crashed and I've got customers yelling at me because I've got, you know, my downtime is going down, my uptime's going down. I'm losing those nines. I had six nines, I'll have five nines, another hour goes back, I have four nines. Yeah, no, I don't wanna do that, right? Okay, so the safest approach here is, remember, we have this problem with writes. Writes are what causes this problem. Reads are not as big of a deal. So the safest approach is simple. Don't buffer writes in the cache. Does this mean that my cache is completely ineffective? What's that? Well, okay, let me ask you a different question. In this case, why do I keep writes in the cache at all? What's the difference between writing back writes immediately, syncing them to disk as soon as they happen, and not caching writes at all? So what happens if I don't cache writes at all? Yeah. Okay, so I think we're moving in the right direction here. So if I modified the block in the cache and then write the contents to disk right away, what other operations does that help? Yeah, Steven. Well, remember, every modification is gonna go to disk right away. So this is not helping writes. There's like one other operation that could have possibly helped, yeah. Yeah, future reads that disk block can hit in the cache, right? If I don't ever buffer written blocks in the cache at all, it means that reads don't benefit from those modifications. So modifying in the cache and then running it to disk means that if I have 50 reads that follow that, they get the latest data from the cache without having to go to disk. Would you keep the writes in the cache? Yeah, that's what I'm saying, right? So, and I'm also gonna pull blocks into the cache even if they're written, right? So when I see a write to a block, if it's in the cache, I modify it and make sure that modification gets to disk immediately. If it's not in the cache, I read it into the cache, modify it and then write the modified result back. But I wanna keep writes in the cache because it helps reads. Now in this case, this is called a write through cache because when you think about it, writes pass essentially write through the cache. Writes pass right through the cache. That's the fun thing to say. So writes immediately, so there's no buffering of writes in the cache. They immediately go to disk. Now on the other hand, so this is the safest approach because remember, essentially what we're fiddling with here is the delay between when things get to the cache and when they actually get to disk. That delay is what creates the potential for consistency problems. So if the safest thing to do is to write blocks immediately, what's the least safe thing to do? Okay, so I have to write them at some point. That's always my favorite answer, like never write them. Yeah, I mean, that's an interesting approach. That will immediately, like, it's awesome. I bought this disk but I can never write anything to it. That would be a very frustrating disk. Do you guys remember this? It was like a few years ago, there was some scam where people sold these, do you guys hear about this? They sold these flash drives and they said they were like a terabyte or something. They're like a thumb drive.  No one would be like, oh, a $2 terabyte thumb drive. Actually some people would, right? But anyway, so they sold these thumb drives and they claimed the capacity was like a terabyte. The capacity was actually only a gigabyte. But they were clever, right? So what they would do is they would store your first gigabyte, right? And then I think they were even more clever in that they would keep storing new stuff but they would just start throwing out crap, right? So it was like, imagine you have a disk that you think is a terabyte but it's actually only has the latest gigabyte of stuff. That was this flash drive. Anyway, they made some money out of it because again, they worked kind of. That was the clever thing, right? They worked at first. So they gave them like a few months to sell these things before people realized, wait, hold on, like, this thing actually doesn't store any data or it doesn't store more than a certain amount. Okay, so I do need to write them at some point but when's the longest I can take before writing them? Yeah. When they get a victim. So a write back cache buffers all operations as long as it can. So until I have to write things, at some point when I remove the block from the cache, this is like removing a page from memory. So a good mental model for a buffer cache is your memory for processes. When I pull it in and make modifications to it, I write it out later. I write it out to swap, right? So in this case, I keep all the operations until I need that block for something else and then I sync it with disk before I evict it, right? And obviously for performance, the approach that's gonna minimize the number of writes is this one, as long as I do a good job of choosing what's in the cache. The one that's gonna be the safest is the first one. And so normally we do something in the middle and there's a variety of ways of splitting the difference between the two of these. So one way is to try to make sure that I immediately write out critical file system metadata. So any changes to on disk data structures like in-use bitmaps, inode tables, whatever, those get written immediately because I wanna make sure that those are on disk. Modifications to data blocks that have file content in them, those I can wait on, no big deal, right? Again, a little bit of data loss, not a huge problem. Having serious consistency problems on my file system because I didn't write out key data structures is a problem. And typically file systems also provide a way for processes to expose some of their semantics. So one of the things that gets interesting here is different programs that are using the file system have their own consistency guarantees that they're trying to provide. And I can do that by making it possible through the system call interface to ask the file system. I'm pretty sure this is always a request, not a demand. Ask that the file system ensure that content for a particular file is on disk. So this is something called sync. And I think, well, sync is supposed to sync the entire file system. F sync allows me to sync one file. So it's a process saying, do your file system, I would like you to make sure that all of the content for this file is on disk. Thank you. And of course there's overhead to doing this. All right, any questions about? So this is the role of caching here. Okay, we're doing good. Okay, so here's another, there's another sort of fun, modern, so these are tools that have been incorporated into modern file systems. A lot of these ideas sort of emerged in particular file systems and then have spread to be used by a bunch of different file systems because they're pretty useful. So let's think about a different way to try to make file system operations atomic. So part of the problem that we're dealing with here, and this is actually a bigger problem than I've identified because remember the file, remember the disk has its own memory cache? If I'm trying to write multiple disk blocks, I may not know when they exactly get to disk because they may be wedged in the disks on drive cache. So rather than trying to make multiple disk operations atomic, on some level, if writing multiple disk blocks is not atomic, if I can't be sure that all of these are on disk, what could be atomic? So again, if I'm writing multiple disks, requires running all over the place and it's very possible that I can get done, I can get interrupted halfway through, something can crash, whatever. In contrast, how do I make sure that a modification to a disk block either happens or doesn't happen? Writing one disk block, so I write one disk block and as long as it just has a way to tell me when that's done, if I fail before I get that right done, it didn't happen if I fail after it did happen. So this is atomic based on the definition we were using earlier in the semester. So this suggests this technique that's known as journaling. So here's how journaling is going to work. When we make modifications to the file system, we're going to write down in a very specific spot what modifications are required to various file system data structures. Then that allows us to keep some of those modifications in the cache. When the modifications are actually made, we're gonna sort of check things off of the list and then periodically we're gonna update the journal to make sure that all the operations that have actually made it to disk are there. Let's walk through an example. So I track, again, there's a special file system, new file system data structures known as the journal. The journal tracks pending changes to the disk. After, so one of the goals of journaling is to make it very fast to recover from failures. Because what the journal allows me to do is when the file system recovers from a failure or when the machine reboots and the file system is reloading itself, it can use the journal to figure out what it was in the middle of doing and identify sort of incomplete operations that I might need to complete or in certain cases, undo. So let's walk through an example of this. So let's, so this is the create and this is sort of creating and writing data to a new file. So here's in a kind of a silly format what I would write in the journal. Obviously there's data structures for doing this. So I basically tell, I put this in the journal that's going to be on disk. I say, I'm going to allocate this inode and I need to be very specific about what I'm doing. I'm allocating an inode for a new file. I've got some data blocks that I've allocated to that inode to store the contents. I'm going to put the inode into a particular directory and I would have to write down both the name and the inode number in that new directory and that's it. So this is a single journal entry that sort of reflects creating a file and associating some new content with it. That make sense? Okay. Now as these changes get pushed to disk, what the file system is doing is updating the journal. So it's keeping track of journal entries that have been completed and when everything up to a certain journal entry has been completed, refer to that as a checkpoint. So that means that the file system at that point knows that all those changes have actually made their way to disk. So for example, let's say that, now these operations can be performed in the cache. Over time, eventually once I know that these changes have been written back to the actual disk, I can check off these things. So once inode 567 has been updated in the inode table, once the data blocks have been associated with that inode, once the directory for inode 33 has been updated with the proper name and everything, I can cross these things off and I can essentially remove this entry from the journal. Because now I know that all of these changes are actually on disk. Does it make sense? Yeah. Gosh, I have no idea. Yeah, I mean, potentially, I mean, journaling, okay, so that's a great point. Journaling and checkpointing is not an idea that's confined to file systems anymore. That's a great point. You can really apply this idea to anything. What it means is you can, you maintain a compact data structure that's easy to write out. So remember, the journal's on disk. The difference here is that the journal is written in one place, and so updating the journal can be done by updating single data blocks one at a time. Whereas all these changes are gonna be all over the place on disk. And so this sort of allows me to get the benefits of having a cache where I hold objects longer without the consistency problems. Okay, let me go through this example and then we'll be done. So on recovery, so let's say I am loading, and this happens every time you mount file systems that use the journal. They never assume that they shut down cleanly. They're always gonna look at the journal that they were maintaining from the last time they were mounted. So when you mount the new file system, what it'll do is it looks through the journal and if there are journal entries that haven't been check pointed, it's gonna update the on disk data structures to complete those operations. So any journal entry that's left after the last checkpoint means that there was some changes that I needed to make that did not make it to disk, or I'm not sure they made it to disk because maybe I got, I rebooted or I crashed before I could update the journal. So in this case, for example, let's say I have this entry in my journal. This entry is not, this entry is after my last checkpoint. The nice thing is it's very fast to confirm that I did these things. So for example, I can look and see if Inode 567 is allocated. If it is, cool, I must have done that already, okay? I can look to make sure that these data blocks are associated with the Inode. In this case, maybe that operation didn't make it to disk. And so now I can make sure that it does. So now I update the on disk data structures appropriately. Again, same thing here. I need to associate this Inode with the directory so that the file is linked into the rest of the directory tree. And then I'm done. So by using the journal entries that are still marked as uncheck pointed, the file system can identify precisely the operations that need to be completed to bring the file system into a consistent state. This makes sense? The nice thing about this is it confines the amount of work that I have to do when I reboot to a very small number of operations. So rather than having to check the consistency of the entire file system, like we were talking about before, I can just make sure that I complete any uncheck pointed journal entries. Okay, we'll start with this on Friday and review it again and then talk about FFS and LFS, maybe.


Hi everyone, welcome to the How to Demonstrate Allyship to the Women in Open Source session. My name is Ratha Jataka, and I'm a Program Manager in the Google Open Source Programs Office. Part of my role is working on DEI in the open source community space and making sure it's more diverse and inclusive for everyone. Hey everyone, my name is Mike Buffano. I also work as a Program Manager in the same org as Ratha at Google. And I've had an opportunity over my many years at Google to work in different capacities in the diversity, equity, and inclusion space. And I'm particularly passionate about engaging in conversations as to how we create welcoming and celebratory environments for everyone at work. We will facilitate this session by reflecting on the experiences of women and main use language referring to gender in the binary of men and women. However, the examples can be applied to a spectrum of gender that includes non-binary folks. There are a multitude of nuanced experiences that we may not be able to adequately address in this session, but we are on the path to creating a more inclusive and welcoming community for all in tech. To give everyone an understanding of how to demonstrate allyship to women, we'll first set the stage, allowing everyone to come together with a basic understanding of concepts we'll be going over. We also thought it would be beneficial to provide some real-world examples to you about the experiences of women in open source. So we sent out a survey and some women felt comfortable enough to share their stories. And lastly, we'll end with some actionable behaviors that folks can take to implement positive change in your work and volunteer contributions. This includes specific behaviors around allyship and revisiting the examples after learning new information and just some thoughts we'd like to share. So we are going to set the stage with a handful of definitions and concepts that are really foundational to any conversation focused on demonstrating allyship. First, it's important for us to define what allyship is here. There are multiple facets to defining allyship. Generally, allyship is defined as acting for equity through the lens of one's own membership in an advantaged group. Another important component is that being an ally is not an identity, but rather an intention. So it's the hope that we are continually expressing a commitment and acts in accordance with this idea. Demonstrating good allyship is not a label that any person can give to oneself. It's a characteristic that is recognized by those two you are an ally. So for example, showing up to a session like this, it's a great step, but it in and of itself does not make you an effective ally in real life situations. We're not going to send you a sticker that you can wear around that's going to say, okay, I'm a good ally now. And lastly, allyship is strengthened by recognizing privilege received from societies injustice and taking responsibility and really diving in and changing patterns. So examples include men working to end sexism, white people working to end racism, and cisgender folks working to end transphobia. So looking at other terms, another important one is microaggression. Microaggressions are just one of many mediums of discrimination. So psychologist, Daryl Wingsu, defines microaggression as brief everyday exchanges that send denigrating messages to certain individuals because of their group membership. So this could be something like asking someone, where are you really from? That's a microaggression when someone may not have a very Anglo sounding name or appearance, saying something like she's a bit bossy as a phrase that could seem as tone policing women. So though microaggressions are subtle and indirect, they leave a person feeling hurt, but in question of whether or not that was their intent, while one microaggression in isolation may not cause over harm or may even be chalked up to a misunderstanding, the accumulation of microaggressions can be overwhelming and reveals common biases at play. Another important term to understand when discussing the different dimensions of identity is intersectionality. Each of us has varied, diverse and complex identities and perspectives. Some of these identities are visible, others are invisible, some of them are majority identities, others aren't, and one person can never capture or know all of them. It's impossible. Dr. Kimberly Crenshaw coined the term intersectionality, the definition of which is, the idea that social identities related systems of oppression, domination or discrimination and multiple group identities intersect to create a whole that is different from the component identities. So originally this term was reflective of the compounding discrimination and oppression faced by women of color that was unique from independently examining communities of women and communities of color by themselves. It's now more broadly used to describe how any set of identities may overlap with varying social impacts. So the theory that because our identities are made up of many categories, we can think of race, class, gender, age, health, et cetera, the more non-majority or underrepresented groups someone typically belongs to, typically the more discrimination they face and the fewer places that they may feel psychologically safe. So the more majority groups that make up someone's identity, the more privileged they will typically have. So for example, when we think about having to deconstruct different systems, women have to deal with sexism and misogyny. Black people have to deal with racism, trans people have to deal with transphobia but a black trans woman will have to deal with racism, sexism and transphobia often at the same time. So they can face misogyny and transphobia in the black community as well as racism and misogyny inside the LGBT community leaving few places to feel psychologically safe. We looked at surveys of the open source industry to see what the number said because we know that metrics are important to open source users and here's what they show. Open source, a large industry that so much technology is built upon does not include many women. From key surveys, one of which was done by GitHub, the data shows the number of women versus men in the industry. From 2002 to 2013 in only about 11 years, the statistic increased only about 9% but this time the survey included non-software contributors likely making up the difference in the numbers. While some of these studies date as far back as 10 years ago, the numbers have not improved by much. The GitHub survey in 2017, just 15 years later only showed a 2% increase in women in open source and even more so with such a small percentage of women in the field and if that 50% having experienced something negative it doesn't create the most welcoming environment for women or set them up for success. So we sent on a survey to collect stories from those who've been affected or observed gender-based microaggressions or harassment within open source communities. Doing this helps us to illustrate that these situations still occur regularly. We had quite a few responses that show both personal and systemic impact that the lack of allyship has had in open source communities. So the first of these examples, I'm frequently the only woman in the room throughout all of my project meetings on any given day. Even if no one makes a direct statement about it this sits on my mind all day and all week and it has for years. The second, my IRC Nick uses a very feminine name. A woman's friend does not, a neutral leaning masculine Nick. I receive multiple random hellos from strange accounts every week. This has never happened to her. We have compared this on and off for years. The pattern has never changed. How do you know when a Linux foundation CFP closes? Because at 11 45 PM on the day of men you haven't spoken to in years or who you barely know will suddenly start flooding your inbox to be on their panel. They suddenly realized there's a gender diversity requirement. I created a plan for a projects working group to share updates with the community each month. It was a requirement that these updates would happen though they rarely did and there was no consequences they didn't. This went on for a while until a male joined the project and suggested to others in leadership, other males that working groups should have monthly updates. Suddenly this was the best idea ever and the leadership rallied around it and made it a priority. The male never pointed out that this was already part of the project governance rather than just run with the praise. Not only was it annoying to have an idea to go ignored until a man suggested it. The leadership learned nothing and things never changed. As an open source maintainer of a largely visible code base on GitHub, I noticed that I got a lot of pushback when I committed alone. This pushback took the form of questioning my implementation choice or prioritizing one bug fix or feature over another. And I noticed my male teammates didn't get the same kind of pushback. I also noticed I got less pushback from community members if I co-committed using the committer field of get comments with another engineer that was male but this was disempowering as a solution. I didn't wanna savior, I wanted an ally. I then tried to create a GitHub username that didn't reveal my gender but that also felt disempowering. I want to live in a world why I'm respected for the work that I do without question and without having to hide who I am to get it. After seeing a handful examples where allyship intervention may have been useful, we'd like to discuss strategies for taking action. We can separate allyship behaviors into three categories, how you show up, ways in which you might have a smaller scale impact and ways in which you might think about having a systemic impact. There are a lot of things we can think about before we enter into a solution that will help to cultivate allyship behaviors. The first is making a conscious effort which may seem like a simple directive but it is a reminder that engaging in allyship behaviors is a choice. Particularly if something doesn't impact you or people close to you, it is easy to just tune out and maintain the status quo. One industry that can draw parallel to open source is that of online gaming. In addition to gender disparities in both environments, the virtual nature of a gaming avatar is not all that dissimilar from someone contributing via an anonymous GitHub user ID. This not only lends to someone making inappropriate comments without consequences, sexism being one example, but also how one might just ignore said comments because it's not their problem. Regularly thinking about issues of gender in your day to day and intervening when necessary will help keep the topic top of mind. When we think about self-awareness, this can take many forms. In one dimension, it can be understanding how your dominant or non-dominant identities impact how you show up to any particular situation. In another, it is understanding that demonstrating appropriate behavior in an open source setting, whether professional or voluntary, is everyone's responsibility. For this reason, it's important to be mindful of intent versus impact. While an action may be made with positive intent or even no intent at all, it can impact each individual quite differently. And at the end of the day, no matter how positive your intent, you will still need to be accountable for your impact. Have a growth mindset, especially when you make a mistake. Just because you have made that mistake once doesn't mean that you are unable to grow and do better. In this vein, keep an eye on your own defensiveness. You will without a doubt continue to make mistakes similar to how we fork code when we want to make improvements upon a project, which can often be met with resistance. Adopting a growth mindset allows you to create a better environment for all those around you. A lot of work in the Allership space can seem reactive. One thing that can help to proactively tune us in to what others in our community are facing is to seek out different perspectives. From the books you read to the people you follow on Twitter, to any other media you consume, what voices are being represented? We can constantly be doing work to educate ourselves about experiences from our own, even if it's simply subscribing to another podcast. Now let's focus on some actions that can be taken by an individual on a smaller scale. Listen to other contributors about their experiences and believe them without derailing by offering alternative explanations or invalidating what they say. So for example, if someone says something like, I feel like this person is leaving really aggressive comments because I'm a woman, rather than saying, really? Well, I know him. He's such a great guy. I've worked with him before. He'd never do that. Say, oh, why do you think that or tell me more? Validate great ideas. Give people credit for the work that is done and especially be mindful of that when it comes to addition franchise groups. Make sure people's ideas are correctly attributed to them and draw attention to their accomplishments. Demonstrate inclusive leadership. Create mechanisms to allow more than the loudest voice to contribute. Call out if you see someone interrupted in meeting, allowing them to finish. Invite people to the table. And by table, we don't just mean meeting room. Take inventory of who is present and engaged and then appropriately close gaps by inviting people and not just as a token representative of one identity to contribute to your projects, events, products. Not only is that the right thing, but research also shows that diversified representation will actually make the final product better. And be inviting all those who are interested in learning more about and practicing open source and encouraging new folks from all backgrounds to join and help open source grow and become more inclusive. And lastly, be mindful of language. Precise language is an important component of effective communication. Don't say girls when you mean women. Avoid words like nag, hysterical, crazy, bossy, aggressive, sweetie, which reinforce harmful stereotypes about women and can be demoralizing. And all of the words I just mentioned are actually research-based and grounded in the experiences of real women today. So calling your colleague sweetie is unfortunately not something of the past as we'd like to believe. And many times people wanna ask, what are a list of words that we shouldn't say? But it isn't really the best approach here. So culture, context, and personal experiences are just a few of many factors that may cause one person to interpret your words differently than another. Helps to be mindful of language, but also to be humble and open to feedback when message comes across in a manner that you didn't intend. This goes as far as the language that we also use in our code and libraries. And an issue that we've launched in the last year or Google is to use inclusive language. Whether at a small team scale or organizationally, there are ways in which we can seek to have a systemic impact. Disrupt work assigned along archaic gender roles or with a distinct lack of representation. This might include creating a clear path and support mechanisms for contributors to become maintainers.  It all starts with having and enforcing a code of conduct. In Ospo at Google, we uphold all of our project partners to implement their code of conducts. An example of this would be to tell your team that you realize you are probably making a lot of mistakes and that you will do your best to notice them and own them in real time, but you welcome input if people have noticed something you may have missed. Those who seek to challenge the process seek innovative ways to change, grow, and improve. This is a way to counteract that this is the way it's always been done mentality. It is important to experiment and take risks by constantly questioning how things are done, identifying the processes that don't work and take actions to fix them. And lastly, generally speak out. Men calling out sexism is often seen as more credible than when done by women themselves. Given that men are part of the out group, it is not perceived as being in self-interest. This runs parallel along other identity dimensions, like why people speaking out against behaviors that perpetuate racism. While we can't provide you with the list of exact right answers for every solution, if your words or behavior could perpetuate inequity for any women, encourage gender stereotypes or cause harm, you should not do or say it. It doesn't matter if the person in question doesn't mind what you said or did. What matters is whether or not any women in the same context or observing would mind and whether you are contributing to an inequitable system. After reviewing some of the specific ways we might demonstrate allyship through our actions, we'd like to revisit some of the scenarios shared by women in open source earlier in the presentation and map them to some of the allyship behaviors we discussed. So looking at this first example of being very apparent, there is only one woman present at all project meetings, we think that this really could be approached by behaviors having a systemic impact. So this situation is an interesting one because it really isn't active, right? That's to say there isn't an overt action or statement where we might point to someone doing the wrong thing. But if we take a zoomed out version or view of the situation, a working group can consider how they might collectively work to make the composition of that group more representative. Even if discomfort wasn't overtly stated by one of the women in the room, it's something that you can take a look at and say, hey, this is a change that we might make here. For the example of securing conference speakers or panelists, we think that this can be influenced by how you show up. When you craft contributions to the broader community with representation in mind from the start, you can avoid having to scramble to meet a requirement or appear as if you are doing the right thing. This can apply to being a panelist yourself. You can commit to participation on the condition that certain benchmarks of representation on that panel are reached. If they aren't, you can inform organizers that you will need to decline. And for this example of how credit was not appropriately attributed to the female contributor, there are behaviors that one might take to have both an individual and a systemic impact. So as an individual who has been working on this project and observing the described situation unfolding, you might speak up in the moment and say something like, I'd actually like to acknowledge the work that's already been done here to set up this requirement and process, citing the colleague who worked on it. In a broader project sense, appropriate attribution and empowerment can be built into the culture of a particular group. So not only might that create a knee-jerk mechanism for leadership to give credit where credit is due, but may also make someone more comfortable speaking up and advocating for themselves because they feel like they have the psychological safety to do so. First, it is crucial to remember that allyship is not linear and it's not easy. You will start, make mistakes, learn and make more mistakes. There is no finish line as we are all continuously learning and growing. The fact that we will never truly finish this work may be frustrating, but know that your improvements are actually making a difference. One thing that should comfort us though is that we already possess the skills needed to demonstrate allyship behaviors, skills like listening, self-awareness, taking and receiving feedback and acknowledgement of and correcting our mistakes are already baked into the most of our day-to-day jobs. It's a matter of paying extra attention to behaviors towards women and other underrepresented groups, being mindful of the unique problems each faces and channeling these skills to be a catalyst for more positive change. Focusing on individuals' behaviors, particularly those who are marginalized and how to navigate systems that were built on racism and sexism does nothing to change these systems. We just wanted to share this quote with you and end on the note that you can make a difference. Thank you.


Since losing part of his mobility to multiple sclerosis, Major John Arbino has earned a spot on the 2013 Warrior Games Army team. Becoming involved in adaptive sports has given him a new outlook on life. Even though I'm in a wheelchair, I can still be competitive in something and I was kind of losing that. I was in a wheelchair. I didn't know what to do with myself anymore. I couldn't compete. I was always a competitive person. As I'm learning, there's a lot of things I could do in a wheelchair. Focusing on his events, shooting, and the wheelchair race, Major Arbino has found himself at the range during the day and in a vacant parking garage at night. That is two. And every time I come down I get one more take. Marking well over 200. So that's what's been done since, I don't know, three months, four months now. 20 ramps each night. So this is my, it's my wheelchair premium grounds. It's nice and quiet up here. I used it to redefine what I was going to do and find the new things I could do, the new abilities that I developed out of disability. While these may be individual sports, no one is going out there alone. I mean, with our team, no, there's only a few of us who race wheelchairs. So when we get out to the training clinics, you know, it's a pretty tight group. There's only three or four of us, so we spend a day on the track, full circles. He'll rejoin his teammates at the Warrior Games. Until then, he'll be at the ramps, pushing towards a stronger finish. From Fort Belvoir, Virginia, I'm Sergeant Rachel Badgley.


Hey guys, just got out of class, headed up to JPEG. The forecast looks spectacular. I'll see you there. Here we are at J. One of the best parts about going to school in Vermont is you have the opportunity to get out and explore the great outdoors just like this. Let's go. University of Vermont offers tons of discounted season passes for some of Vermont's premium resorts through the Ski and Snowboard Club, which is the largest in the nation. All the mountains are within an hour and 20 minutes of PBM's campus. The Ski and Snowboard Club provides buses for students who don't have cars, and if you're like me and you base your schedule around skiing, you can always find the time to get on the mountain. Here we are at the summit. As you can tell, it's a little bit cold, a little bit windy. My conditions are awesome. Let's get after it. Guys, just finished an excellent day on the slopes. The best part is I woke up, went to my classes, skied, and now I'm going to be back in time to have dinner with my friends. This is just one of the things, one of the many things, that makes UVM such a special school. Thanks for joining me.


Soonga, soonga, soonga na we Mi ya tene na ngaia wa satcha mwastu ni wana soonga na yei yei What's that? Right there That is a very beautiful song Who is the lady with you over there? She is my friend Tuna chach na yei yei But to me grow spiritually piwa pamoja I wonder ma, nanda kumana na Okay, I understand now What is your lovely name? My full name is Naito linda chep kemoi Tell us about yourself Lenda Apart from music, because I want you to understand this particular point Apart from music, what do you do? Apart from music, I am a fashion designer by profession Sipole ni bass I am very excited, you look amazing Thank you so much I really like that people can extend themselves Yes If it's art, it's art in any other form I really like it Na pia na wana wanga zeti pesa na ne I can't help it, we must be looking for things And they have told you, you're watching my morning I don't know if it's true story That's what I call Facebook Why 254chana on Twitter 254chana on that gram Welcome to the show You sound amazing even in real life Tell us about that particular song, soonga Soonga basically nili yandika Soonga according to what I was going through in my life So nili feel na ni diku press on Like despite the fact that life na ni Na try kuni pull down But na faku stand up boldly na ku songa Yes If it's okay, what were you going through at the time? A lot of things A lot of Nili kwa personal life Yangu Nili kwa unstable business Nili kwa na go through to a lot Sana, sana, sana Ni kwa fikiria The only way na zakuwa Na zakuwa na strength Ni kwa ndatu kwa studio In fact, si kwa iplaniya that song But Nili ndatu studio So boom, nika pewa instruments Naka na go through size Ni ndike tu na faku songa And that's how I came up with the song And the other lady tulifanya na iaie I met her Tuliku na iaie church Ni kama mbe buni a company to nda studio Then uski e kuna kumaflani nili pewa instruments But Nili na feel unafaku kwa apu So tulitu kwa church evening service Tuliku na nda nda studio So kwa fika puni kama mbe na buni Usi vibe kwa ingoma Tukapata upaku And that's how Tukasonga In studio ikawapia Nini pite pite apu baby Ikodonhum Na bidewe ni iaitu Really? Like you own it? Yes Look at it I would be telling all the village then Ah village? Really? When was it birthed to seme? Established This year In fact Songa na Tukona wasani wengine wa wili In fact So ni angundili kwa the first song kutoka kwa iaie studio And by the way, studio ni itwa G vibes ikodonhum Savannah area Yes I speak fluent in fact Thurs day vibes See what I did there Okay I have so many questions So many questions to ask I don't even know where to start and pick from Okay this is you going through things Sindio na life niya mkufi niya ilia oku edi Ilia weni tunafiniwa sa inama futa I don't even know where to begin Why not give up? Okay I don't want to say everyone Some points You kwa ni sitwa chetuiki tu bas Kwa ni keesho Will I die if I live it? No I won't So why are we continuing to struggle and struggle When won't you give up? Si kwa give up because I was born to win Eh Nakunamita me tokatuwa pana Nia yoku gonfide I really like it So ni ki kachini Ni ki restructure life yungun na mimi personally I'm not supposed to give up in any way Ata aland loda kia anza? Akuna So mi nim say Akuna kitu yung ni sitwa by the way Juna jua everything To make it at hand God na kupenga whatever Ana kupenga anything wuna is a hand only So Ni ki kachini na nina jua Ni kwa kawzitofu lani na pitiya Na jua ni God aliyona na naizai handled So I'm always grateful I don't question him why Why me Lord Na jua Nimi umeni chagwa Ni takonka God kumbe na huangadiftenia That's not what you may tell me Una ni feyya Ni sawa mi badonda kupenda Laki ni wae ni feyya to But God appendi complains Wala ai Append Appendi complains at all He did say his world first is to be grateful So to wacha Mi nim ni ati complains Acha na na complains Wacha complains So ni ane to da gradually Mombi itu asanti Na ni ki ni feyya sara ni Mombi itu asanti Una jua di mi ni tu na mombi asanti Anafil wuna jua God anapenda Kwanza wu mombi asanti God Like na kupenda Like kaku na umtutuka Una jua God anapenda praise Like wukin praise In whatever situation you are in Usia nze gai wae mi Umambi itu enye we It's me and I'll handle this First someone is just enjoying me So I'm getting life advice from my guest Excuse me What is your latest song? No, what was your first song? First song ili kwaiali umetenda It's like atangoma zangu zote Mi urestructure na whatever Umekwa Vene wasani yu kunamtu ata Andika ngoma According to labda we ni beshite yunguna There are some things you are going through Nita andika songs Kwen courage mu tu about your life What you are going through Junafil Whatever you are going through Kuna mse mungine pia na go through Na kuna bitutu So kunamtu kami mi Na filiangu ni ushuhu dainafi akum Kwen biawa say Na goda kikubali place to fike Una ni ambiawa what you are going through Na mse mandio Tuna andika ngoma through your situations How long does it take you to write a song? In fact Minutes Wow Someone has to hire Someone has kumandike Yes, ni nae mani grace But na believe For gospel artist like me Una involve mungu before the process So ni kijua na fakwenda studio To say my next week I do pray a lot about it I sit down na ambia God guide me through Na sit a struggle Na trust me kuna time to link ya studio ju Studio yungu Tu na kuwangana ok mi wuhaya producer Di oni kwen a different touch of music That's very smart So kuna time to link a boy flania kakam Ok, yes i mention him But trust me kama ata kuwa studio akuna neyema Witu zita kwa crashed The boy was like Una na mse ni kana chomeka Like I've never handled watuka nyi nyi Adi tukanda kongali na tukanda Watuka nyi nyi Because the first thing to kingya studio lazima wombe Ambia God let whatever ina kuwa produced apa I change mu tu i bless mu tu I inu tu mu tu yo yote So mu tu a li kuwa anakachini ana amuka Ana skia na chomeka Mpa kaka seman tawapia tu instrumental Just go like Mpa ngekila kitu then call me So he lifa to meet the next day So he was like Nime kuwa busy But niki kuwa free I'll call you Ajawai Reason being To li involve mungu Na maybe God a ku taka Tu wak nae So wuki wom sana Most sana sana Gospel artist Okay, see, see, see Necessarily at a gospel artist But mu tu yo yote tu na faku eka mu wombe le Uta struggle Kila kitu ita flow So to me nani take minutes because Na kuonga prepared From the word go Na omba Na naji wa niki enda studio Thimi asongi anu ina fakuwa These and these So whatever will be singing ina fakuwa Inside that box So ita nipia Humble time Na plus Ukipata producer mu na naji wa kitu anafanya Anafaku ku guide Way through Sana sana I do prefer working with somebody Who knows to sing How to sing Ju uta imbabi tuza kwa po Pia ata skia kin Ata skia kin anakwambia po Meni enjoy And like kumse mu na naka tu chinia Na record tu bora ku record tu Ina fa Umtu ata iana Ana record kitu ana skia Inewe Iniki tubo I like that you take quality serious Not just giving us five songs in a week Na zotizana sound a little bit Outside Outside Not the when we will be saying Oh we outside No zikonjen nani We outside as testifies Kuna ime imflani Ata nisi cementa Na sound kani nashout Na stuck ita kusani as a way We should have a good morning, right? Kuna salam mam Kwe Nimi giva Nisi umluia Na salimia ma fans too wangu Ome kwa kini support all through Relatives wangu Sanda sana my aunt anakwanga Uko apileo Nive ni ko job Nge kudrop Uta kwa wapi wacha to stream live So she so supportive Na two Cousin sto angu Uwana kuwanga sana apu na apu kuni 40 liya Uwana ni onwanga kama stana But do I say When star Na kubali na yama Na wasalimia sana Video director Thanks so much Yaw ni push sana Kwa industry Anitwa Byron F.O G Vibes studio Entayali kila mtu Salam ulist ni rifu Uki anzaku mention names Wangi na utasimambu na ukuni salimia Na wasalimia wote Na wa shukuru sana for the support Na let's pray for each other Kila kititaku wasawa Na by that na tonight Vote it this year to see fight Mista kiku fight Okay we pray for that man Let's not nia don't want to fight this year Hashtag is Thursday vibes You're very graceful Thank you for coming to show It's a good day to come to work Na ni Na chanta puli zeyo ni maiatende Ni umeni angalia To see aribu unita fute Due to public demand Wana taka utu wimbe bila wewe Bila wewe Say Now comment na ni Miminita endawapi Bila wewe Na tena ni tafanya Ni ni bila pensilako Miminita endawapi Bila wewe Na tena ni tafanya Ni ni bila pensilako Come to ma Come to ma


In this module, we shall look at the actual use of an Islamic credit card and its implications for payment by the card holder, especially the card fee and of course the payment of the monthly payment balance. Now, we start with an example of a credit limit of 100,000 dirhams and the card fee is actually 6000 dirhams. For the sake of simplicity, we would like to assume this figure which gives us a monthly card fee of 500 dirhams, which is quite a realistic figure to assume for a card fee in the market of the United Arab Emirates. Now, this is a familiar picture for you. We have referred to it previously. There is a card holder, there is a card provider and using the credit card, the card holder makes numerous transactions at various places and we saw that all this record comes to the card holder at the end of the month or at the start of the new month in the form of a statement. Now, if we assume that this card holder actually makes only three transactions in this month, transaction number one was made at store one for 1500 dirhams. The card holder bought something, take clothes, okay. Another transaction was made at store two. The card holder maybe bought some groceries and 45 dirhams were spent on a kiosk. Maybe the person wanted to have a quick coffee or any cold drink and so the total statement balance would be 8,000, 1,890 dirhams. Now, if the customer, the credit card holder pays this amount by the payment date, he would be a transactor so he will not have to pay any interest on this amount of 1,800 something. However, if the card holder is a revolver, i.e., he does not pay the full monthly statement balance but rather prefers to pay only a part of it. If that happens then the customer would have to pay a card fee for the month which would be 500 dirhams. Let us assume that the card holder actually pays only 200 dirhams out of the monthly statement balance. In that case, the next monthly statement will include the following. Of course, new transactions, the customer, the card holder would be making during that period plus the balance carried forward from the previous month which would be the previous month's monthly statement balance minus 200 dirhams which the card holder paid. This would be 1,690 plus the monthly fee of 500 dirhams. That would be on the monthly statement for this card holder following the saga of him becoming a revolver. This figure, in this example, this might sound very exorbitant. In this example, actually we are facing 29.58% per month return which is a lot of money. But this is an exaggerated kind of hypothetical example. In reality, this figure, the return figure could be quite reasonable and actually in some cases it could be quite favorable for the card holder. Remember, we are referring to an Islamic credit card, not a conventional credit card in this example. Now, let us use an example where the use of the credit card by the revolver could be actually quite favorable. If the monthly statement balance was 90,000 dirhams, remember this customer had a credit limit of 100,000 dirhams, so 90,000 is still within that limit. Now, if the card holder decided to pay only 1,000 out of it using a hypothetical figure, normally the card providers, they ask you to pay 5%, the minimum payment is about 5% of the balance. But in this example, we are using just a figure. The conclusions would be valid even if you put 5,000 dirhams over here. Now in that case, the next monthly balance would include new transactions, 89,000 balance carried forward from the previous month and the monthly fee of 500 dirhams. This would amount to only 0.56% per month or roughly about 6.74% return on an annual basis. This actually looks quite reasonable and if this whole thing is studied for one year for this customer, we might find that this customer is benefiting a lot from its or his or her holding of an Islamic credit card. In many cases, Islamic credit cards are actually a lot more beneficial in terms of economic benefits for their card holders.


A governorship candidate of the all-progressive Congress, ABC, in Kogi State, Usman Ododo on Friday, received President Mohamedu Buhari's blessings as the party's flag bearer in the November election. Ododo, while briefing State House correspondents after he was presented to the president by Governor Yahya Bello, said he was committed to building on the developmental strides of Bello if elected in the forthcoming polls. The ABC candidate said that he was confident of ABC's victory in the November governorship election. As a tradition, we have a father who, by the special grace of God, came about this all-progressive Congress in the passing of President Mohamedu Buhari, the leader of our party. So it is our tradition to present our candidates to our father and our president. To that is exactly what I came to do today. I have presented our candidate, Alhaji Osman Ododo, to our president, President Mohamedu Buhari, and he has given his blessings and admonition to him, myself, and as usual to all Nigerians. To minister first, a party man, to continue to serve our people to the best of our ability. Kogistit is not known for agbeiru kind of leadership. Kogistit is known for an inclusive leadership and a leader that will give way and allow the younger ones to come on board. He's a young man, a young fire younger than me, and by the special grace of God, all the young people are women, and even the elderly in the society will be carried along in the next administration as much as I have done. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.


We want to give you a big, big thank you for coming out, being supportive, running or walking, donating, whatever it is, we want to appreciate that you are setting up to make a difference in the Tri-Cities. We want to invite you for the next 5K annual run for next year. Make sure to come out, invite your friends, invite family and your children and we will stand and make a difference together.


Hi, this is Tracy Takahama Espinosa. Thanks for the opportunity to talk to you a little bit about mind-brain education and getting rid of neuro myths and teacher practices. The brain has unlimited capacity for memory. Unfortunately, the brain is a physical entity, so it has a physical limit to it, though we don't know exactly what that is. Memorization is unnecessary for learning and unwanted in modern education. Memory is needed for learning. What we don't want is people memorizing, for example, the times table or grammatical rules without context. Then it's not transferable. You can't use it in a new context. So memorization is vital for learning. What we don't want, though, are just memoristic activities. The brain remembers everything it has ever experienced. Forgetting is due to bad encoding. While forgetting might be, in some cases, due to bad encoding, forgetting can also be due to multiple other factors. There are multiple reasons people forget and multiple ways that people can remember, and so it's not as easy as just what is memory. There are multiple subsets of memory that teachers need to be aware of as well. Learning can be isolated from the social and emotional context. Myth. All learning is emotionally engaging, so every decision is based on an emotional context as well. Reasoning and decision-making can be divorced from emotion and feeling, and in doing so, this improves the quality of thought. Not true. The emotion will still be experienced. The way you feel that emotion is something that you can manipulate, but you cannot change the emotion, which is based on chemical releases and from the brain to the body. Those things will not change. Languages are located in the left hemisphere of the brain. Absolutely wrong. In fact, there's huge networks that have to do with human interpretation, intonation, that are far more right hemisphere dependent, so this is just not true. It's not that there's a left and right division of responsibilities for domain areas like language. Children must acquire their native language first before learning a second language. Absolutely not true, and I have living proof in my three children who are brought up with four languages. You can learn multiple languages at the same time. Children are sponges and learn foreign languages effortlessly. Believe it or not, it takes a whole lot of effort to learn language. We just think relatively speaking, it seems like less effort than we put into learning languages. But it is not an effortless task. It does take a lot of energy out of those things. Not an effortless task.


And also outside Africa, President Vladimir Putin has praised members of Russia's military and security forces in a ceremony that he set to reassert his authority, throwing an aborted miterney by mercenaries led by the Wagner group Chief Prigazin. A jet linked to a prigazin arrived in Belarus from Russia, believed to be carrying the mercenary boss into exile three days after he abruptly called off his miterney with his fighters bearing down on the Capitol. Authorities dropped a criminal case against Wagner, the state's agency reported, apparently fulfilling one condition of a deal agreed late on Saturday that defused the crisis. Putin told some 2,500 security personnel mustered on a square in the Kremlin complex that the people and the armed forces had stood together in opposition to the rebel mercenaries.


Five alternatives to confronting the narcissist. There's no point confronting the narcissist They're not even listening to you. They don't care about anything you have to say Because they're not going to entertain anything that is unfavorable to them They don't care about what is right or true They're only concerned with whatever benefits them one Do not confront them if you confront the narcissist It isn't going to solve anything it could cause more problems Narcissists are high conflict people They engage in behavior that increases conflict Rather than reducing it or resolving it if you confront the narcissist It will only confirm to you just how toxic they are It's bad for your health to be around these types of people So don't even bother confronting them Then you can avoid the problems that would otherwise come along with it If you confront the narcissist They're not just going to look at themselves and realize that they need to change They think that you're the problem They can't see anything wrong with themselves So don't waste your energy confronting them It's not going to change anything to use the knowledge and experience you have gained to guide you You may have watched my videos And now you understand narcissism You figure them out You know what they are You know why they act this way And now you want to bring this knowledge to the narcissist Because you think that it's going to solve something But the narcissist isn't going to hear it They're just going to turn it against you They're going to call you the narcissist So instead of confronting the narcissist Take the information you've learned And use it to decide what you are going to do next Use it to help you make decisions in any situations with other people in the future So that you can make better choices 3 Gray rock If you have to communicate with the narcissist Do it in an uninteresting way Become unresponsive Or even avoid interactions with the narcissist Don't share too much information with them As they will only invalidate it Don't share your achievements As they will only minimize them Don't share your feelings with them As they don't have empathy anyway They will only leave you feeling unheared So don't share anything significant with them 4 Talk to people who you can trust Talk to people who support you Talk to people who understand Whether it's a friend or therapist If anyone invalidates what you are experiencing Spend less time with them Go gray rock with them too You need to surround yourself with people who do get it People who make you feel understood 5 Acceptance You need to accept that this situation is out of your control But do not judge the situation You need to manage your expectations And accept them for who they are And realize that there's really no point in confronting them Do not confront the narcissist They're not going to change They're not going to self-reflect It's just going to cause a narcissistic injury Which will be followed by narcissistic rage And their rage will affect other people that you care about Whether it's children, family members or friends Their rage affects everyone It will distract you from other aspects of your life It will cause you anxiety and stress The narcissist will always be angry and resentful And there's really nothing you can do to change that You need to accept that it is not your responsibility to fix them Focus on protecting yourself Because the emotional manipulation will make you ill Sadly, our societal systems are set up to enable these types of people And to put them in positions of power So you may not get to see them get the punishment that they deserve But that should not be your focus anyway Focus on protecting yourself Focus on self-preservation Thank you for watching I hope this video resonates with you Please like, comment, share and subscribe If you would like to donate My paypal link is in the video description Coaching inquiries You can email me at culture.nax survivor.co.uk Thank you for watching and I'll talk to you soon