Just for who doesn't know, this is Mr. James, and he's going to present MGMT config for containers. Thank you so much. Applause. So I'm just going to talk a little bit about containers, because it's such a hot topic. And a little bit about why we don't treat containers exactly like other resources.  We're going to talk about that. I'll show you some videos. Who am I? I'm a hacker. I talk really fast, because I have a lot of stuff.  So if you really miss something, and you really desperately don't understand, raise your hand, and I'll try and answer quick questions. But I'm going to try and show you a lot of demos, and it's recorded, so you can watch it and slow at the end. I write a technical blog called The Technical Blog of James. Who's seen it? Just raise your hand. If you haven't seen it, just raise your hand, so I seem really popular. Thank you. Excellent. I work on, I used to be a physiologist. That's what I did by training in, and I don't really do much anymore. But if you have cardiology questions, I can try and help you out. I was big into DevOps. I used to do a lot of puppets. Who's done some puppet before? No, okay, so you know what I'm talking about a bit. A lot of infrastructure automation. I learned a lot of puppet, but I thought there were a lot of things wrong with it. And I realized very recently that I didn't really want to live in this Kubernetes monoculture. Do you want to live in this Kubernetes monoculture? Who said, yeah, get out of this room now. So this is my answer to whether I really want to live in that world, because it's just silly. It might be useful for some things. So this is my nope guy. Everything is nope. So instead, long story short, some time back I started, I sat down, I started working on a project called MGMT. It was really intended as a solution to the problems in puppet, but I think there's some overlap with what people are doing with Kubernetes and how they're doing it wrong. So I'm going to talk about that and hopefully convince you. So in this project, all open source, free software, whatever, there's two parts. There's the engine and the language. The engine actually does the work on the computer, so it sets up containers, VMs, files, packages, services, et cetera. Then there's the language, which is actually what we use to describe everything to the containers. So, oops, sorry about that. So there's three main parts to the engine. It can run in parallel. There's events, which I'll show you in a moment. And the whole thing works as a distributed system. So it's in contrast to something like Kubernetes for example, which is really a central orchestrator. The graphs that we run, we run graphs. That's our output. And these things are resources. So this might be install a package, start a service, and so on. And these black arrows are dependencies. So it's something you might really meet. Similar to what you might be familiar with, Puppet, and so on. Except we can run everything in parallel. And the events can be anything. They can be files, service. The resources can be anything. They can be files, services, packages, and spawn resources, kind of container thing. Docker containers, if you're into Docker. I'm personally not, but I'll show you a little demo of what I mean by event driven. So let me just actually... So... I have to actually turn off... Is this big enough? Can you see? No. No? Bigger? Yes, no? Don't be shy. Is it big enough? Bigger? Okay.  I'm going to show you just... I'm going to start with a little example. Where I go... So I'm going to run this resource that basically says, please create one container, one file. And if we go into this directory here on the left, you can see... I can show you that it's created this file called Hello World. And if I remove the file, you can see it comes right back. So I remove it and it comes right back. And this is what I mean by event. So each resource actually is being watched by the engine. And whenever something goes wrong, it's so fast it even comes back before it gets to the end there. And this is not fake, you can see the engine running as this happens. So it sleeps and it wakes up. And it's so fast you can even run it in this watch command which just loops something over and over again really, really quickly. And you'll see that it just always sort of keeps you in the correct state. And I have actually an example with an N spawn resource if you'd like to see that. So N spawn zero. And this is actually kind of new so I have to see if this is going to work because there's a bug actually in this resource. But I wanted to show you it anyways. I think it's actually not working right now. I have one second to kill this. N spawn. So if you wanted to do an N spawn resource, you can do it just like this. Just basically declare the resource. And I have this demo. So I was working on a fancier demo with N spawn. But I'm not actually going to show you that right now. So I can actually just show you. I'm going to show you this one because I was really working to get this ready. Sorry, one second. What's my password? Who knows my root password? Anybody? So I used Fedoro on my laptop. I actually wanted to do a Debian demo. So this is what it is. So it's actually, you just need the name of the machine. See if this works. So these are just the declarative resources. And if I go back here and I run this one here, I think that's going to work. All right. So machine CTL, I think it's a list. And there you can see it's running. And the same sort of thing happens. Like if you, I forget if it's terminate stretch. Oops.  Does that make sense? Cool. So I like demo with a little bit. I just had to get it ready for you. So this is the whole point. So we have these primitives. They all have events. Now let's do some fancier stuff. And this works for everything. Virtual machines, files, packages, services. And I think this is actually kind of like monitoring. So typically we had set up infrastructure in a second step. But if we build this in this event driven nature into each resource, it's already partially done for you. So now we have to describe how you actually tell the computers what to do. So normally like in the Kubernetes land and Ansible land it's blasting these giant YAML files which to me makes no sense because it's not expressive. You can only play with the knobs that they've programmed for you.  The language has to be really safe because you don't want to make an off-by-one error and blow away a data center. It has to be very powerful so it's a reactive language kind of like an FRP. If you know what FRPs are, that's okay. You'll understand in a minute. And here's the demo I'm going to show you. So what I do here, I can actually start off this demo. I'm going to start off this demo on the left and on the right here I'm just going to watch this file. Here we go. So what's happening? I'm running this code and here's what it basically looks like. I have this datetime function at the top and it adds the value from this output to a year which is some variable that has a whole bunch of integers multiplied together. Then there's this load value down here and it goes into this variable and then both of those variables go into this struct which gets put into this big printf string which gets set as the content of this file. So what's going on? But here's what's happening when it's running. Sorry. Here's what's happening when it's running. On the left you have MGMT running. On the right I'm just watching this file just so you can see what the output is. You can see it's actually changing about every second because MGMT is actually constantly running constantly deciding that the value should be different in the file and it's updating the file every second. So what's actually happening here is this datetime function is actually a stream of values. So it's the stream of number of seconds every second that goes by. So the data is always going up and it's putting all these values. It changes constantly. Putting all those values and it's re-evaluating just the parts of the code that it needs to which ultimately results in this file resource that has different contents. See that? And then that all gets put into this file and you can see that it actually changes. Does that make sense? And just to make it a little bit more fun I actually built a function, a custom function called VU Meter and what it's doing it's running. It's actually listening to my laptop microphone right now. And just to prove you this is real we're going to be very quiet and when I point to you I want you to make a whole lot of noise and see that it's working, okay? So nothing I could do and so this is the kind of thing we're taking real-time event sources and we're integrating them in this small, simple, safe language that lets you do very powerful things. So the kind of things you could do for example is you could take this and maybe you have this in your server room or in your little office and when there's lots of loud noises and people are screaming and fighting you automatically set all your systems read only so that's the kind of joke I make. So that's the sort of idea but you want to see some more stuff? Do you want to hear some more stuff? These people leaving are like nope I don't want to see some more stuff. Alright so we're going to do some fancy scheduling stuff. So in addition to just these silly examples we actually as I said work as a distributed system and we've built into the core of MGMT some functions and one of the special functions is called schedule and what it does is it actually takes all the machines that run it and produces a list of machines that are selected by a distributed scheduler. So what it's going to do it's going to do this and it's going to run in each machine so I'm going to just run it. This is actually a new demo so let's see if this works well. So I'm going to run it one at a time and oops schedule schedule dash docker so I decided to do this with a docker so I'm going to run the first one and over here and run a watch. I'm going to run this big fancy watch command and what it does is it's just going to sleep and it's going to tail some files and run docker ps and sleep and so on. So I'm just going to run that and you actually can see at the moment this is running. Did it work? The docker thing is quite new so let's see what's going on.  Oh I don't have internet. That's why. I need some internet. Sorry folks. If you're torrenting please turn off your torrents. It doesn't need a lot of internet because I pre-cached the images but docker is sneaky about this stuff. We have internet just kill this I'll start this up I need to CTL start Okay it's working. This is the first machine and what it did is it basically had it right to a text file if you're scheduled write it off. The first machine says I'm scheduled and it decided out of the available host currently there's only one this is the only one therefore I'm only a schedule on the host the first one. What you can actually see down here is one container was automatically created 24 seconds ago and instead of running four different VMs to do all this I'm just doing it all locally the machine is named D-hostname so H1, H2, H3 Let's run the second one and see what happens. I'm going to run the second MDMT they'll automatically cluster together and if we're lucky you can see now that it starts up and in a second now we see a second container running because MDMT decided I have two hosts available I asked for two containers to be running I'm going to put one on H1, one on H2 and you can see them running here and H1 down below. Do you see that? And each host is actually creating a text file just so it can visualize what's happening this is the text file from the first host that says I am scheduled and H1 and H2 are the two hosts in the schedule set. Does that make sense? Just a cheap little schedule. You want to start a third one? Come on, do you want to see a third one? All right, so the third one now I've only asked for two things to be scheduled so if you look at the example so watch what happens, nothing happens because there's only two and we've asked for two, a max of two and a TTL of ten so now if we were to actually shut down the second one we're going to shut down nicely watch what happens we shut down that. Oh, two went away and automatically the first one has said now we've got to reschedule to host three so H3 and then the third one finally came up we're going to have H3 and now you see we've got container H3 and container H1 running do you see that? H2 it's not going to flop because we don't want it to flop back and forth so it should get started up and actually it decided in this case to actually switch it so normally it's fairly static but you get the idea and so what we've basically done is with a very simple built-in function we've allowed, I built in like an hour, a custom little tiny play scheduler now this is just a silly schedule you could build something much more complicated that has a fancier scheduling algorithm like around Robin strategy and so on but that's the basic idea instead of building this huge monolith that has all these built-in components and built-in knobs I decided to build this engine in this language that allows you to put in whatever resource you want whether it's container, docker, nspawn, whatever and then other pieces that glue together to build what you want you might not have to write the code for this in the future someone just might write a scheduling package that does all this stuff for you and you just say what images you want to run but that's the basic idea any quick questions? wanna see some more stuff? you're like somewhat enthusiastic, it's very warm in this room it's like 300 Celsius so that's the scheduling thing you can kill this I'm just gonna actually kill it violently so I want it to go away so we can do another demo and you can, all this code is online so you can play with this at home so I said you don't need to have nspawn this could be a vert resource or anything else I think the Kubernetes project actually made a mistake by sort of hard coding the idea of containers as their primary thing but their opinion ended that way and I think that as a result because they were so specific about that one solution and that's the thing forever it's caused a lot of problems in the codebase very difficult to change the project for the future so what is this? this is a great example because this room is a million Celsius what is this? it's a photo I took in my parents house you can see it's in the international units of Celsius it's very warm I found a clear picture in some sort of arbitrary sauna units on the internet and these things have actually a very interesting property does anyone know what it is? hysteresis hysteresis you saw my sock before okay that's great you're just a smart gentleman so it's hysteresis and what hysteresis is it's also smart if you saw my talk but that's okay hysteresis is the property so let's say you get up to 20 you ask please set your temperature to 20 Celsius the temperature goes up and hits 20 then immediately clicks off and then heats up again it goes back and forth this would be a big disaster we don't want this to happen so hysteresis actually we have the most enthusiastic sign waivers like 10 minutes left I know don't worry thank you hire this man he needs a sign waving job so hysteresis stops that flopping back and forth so you can actually wait some amount of time to go threshold and I'm going to show you you want to see a demo of that come on do you want to see a demo who else is live demoing for you okay so I'm going to run this hysteresis example instead of containers I'm going to use virtual machines just because it's a little change and I'm going to run so I'm going to run this watch command over here it's going to print out the contents of this text file and run verse list and what you can see I'm actually it's mgmt on the left two virtual machines one and two and what I've actually done is it's also printing out the system load so the kernel generates a new system load value every five seconds and I've built in a threshold of 1.5 and the idea is that once we hit 1.5 we're asking mgmt to automatically shut down one of the VMs right there's too much load too much traffic so we're going to move that to some other machine somewhere and schedule it elsewhere and so we're going to do that but then when the load drops below 1.5 we don't want to reschedule that in this case for 10 seconds so let's try that does that make sense so I'm just going to artificially increase the load just so that imagine the VM is doing a whole bunch of work I just got a trick Linux into thinking it's busy oops so we're going to do that my poor little laptop is hot enough as it is it's going to be on fire after this so CPUs are going okay so you saw the first machine was there and the second machine disappeared you saw that we're just watching it and it's past 1.5 and we're going to watch it go down so it's still there and below 1.5 it's going to take 10 seconds so we're still not there 1.8 mgmt is still running it's just waiting watching the threshold reevaluating the code every time something changes 1.6 1.62 any second keep watching for it so it's below 1.5 nothing happened right we're waiting 10 seconds and then it should hopefully start it up again 1.3 so 5 seconds left 3 2 1 boom and it started right back up you like that? thank you so again if you wanted to build something like this with existing tools like Kubernetes you'd have to find some special knob that some programmer spent tons of time building and that's just absurd because there's always going to be some special infrastructure that's different that you want to do something custom your way without making it too complicated and again you don't have to necessarily build all this stuff you could actually have someone else who wrote a module that does the general things that you use so a bunch of companies use the same you know scheduling container module up to you but the point is it's possible and it's very easy you want to see some more stuff? how much time do we have left? let's see I gotta actually shut this down 10 minutes left awesome so I have some time I'm just gonna actually destroy these VMs I'll get some my poor laptop get some love so just some interesting properties about this stuff so the language in the engine these two parts there's actually a bit of a separation between the two so in theory the code actually is safe and it shouldn't crash but if there is some disaster that happens the engine can keep running even if the code actually hits an error it's actually a safe language so there's no nils you can't have like a nil pointer exception in these kinds of bugs it's an immutable language so if you did something like x equals 5 then x equals 6 it would be a compile time error and the whole idea is to eliminate classes of errors before you run the code in production so it's pretty cool you might remember that earlier example I showed where things were kind of out of order you're like what is this guy doing date times up here and the variables down there and the reason I did this is actually kind of as an example because the code actually doesn't need to be in a certain order the code is actually a graph it's just streams going from vertex to vertex of data so the code can actually be written in out of order now you shouldn't do this in practice you would be insane but just an example to show you that the engine the language engine doesn't actually care if it uses the code and it follows the data paths does that make sense? yeah it's a bit of a strange concept I talked to you about immutable variables I've shown you some hysteresis so there's different kinds of hysteresis that based on a time limit or distance things like that so all sorts of fun stuff hysteresis is actually very important because hysteresis is actually a real world thing that our brains are sort of programmed to understand for example if your toaster is not working you push the toaster thing in and the toaster doesn't work you might like you don't try right away again or you try once right away and then you wait you think why isn't the toaster working and then you try again so these delays and these backoffs and these logical things that humans do are actually possible because we think in time so this reactive language is a time based language for this reason it models real life and the idea is basically for error scenarios in real life instead of getting a page and having to wake up and fix something you just program in advance what the language should do for every second of the day in every situation possible and then you have built an automatic sysadmin hopefully good idea right? yeah some people are like yes so this is some stuff we've talked about this is the important module system I'm going to be talking about it at a different conference and I'll show you about it at the end and there's still a lot to do with this project it's still a relatively new project it's not big and fancy there's still some new stuff we need to do in the standard library there's a whole bunch of new functions that would be great to add new features and stuff are always something we need to do there's a bit of code we need to clean up that's a bit messy there's a few bugs and annoying things some legacy stuff that I didn't know better at the time and this is all about you how can you help? do you want to help? I'm going to leave do you want to help? yeah all right so what can you do? you can use this test it, patch it, share it, document it start it blog it, tweet it discuss it just hack on this stuff right this is like hacking stuff MGMT I worked at a mostly cool tech company and I left a little while back to sort of work on this full time because I'm trying to do the free software thing but the bad thing is I don't have really any money to do this I'm just living off my savings so if you want to help like send patches or money or both that's cool I have Patreon it's just an attempt to see if it's helpful and finding a hacker it's very sexy so don't be shy if you want to be sexy this is the easy way let's just recap there's no audio this is just a bad joke of Arthur Benjamin putting the cat back on his pen it's a bad joke I reuse all my jokes and I apologize so if you want to get involved we have an IRC channel MGMT config on free node we hang out I see at least one MGMT contributor in the room so join us we have a Twitter account and a mailing list which you can hang out and listen to there's a technical blog of James you all know about it now so you can check out RSS and read all the great blog posts I write I'm purple idea at IRC and Twitter and GitHub and so on so you can find me there more stuff today I'm actually somehow a main track talk just too bad so I gave a whole bunch of talks already which is just absurd that was sorry that was yesterday and then today I have one more talk in the config management and monitoring room which is basically just a five minute lightning talk so you probably won't see anything new but it never ends and these old talks you can go see the recordings of I showed some different demos and different stuff and talked faster so if you want to there's this really cool conference called config management camp which is happening tomorrow and the day after in Ghent giving two talks and Felix is also giving another talk who's a great contributor as well and on the sixth right after that conference in Ghent as part of it there's a hackathon so if you want to actually get your hands on MGMT with me and some other people writing code writing your own function writing your own resource doing stuff come check it out totally free totally cool if you like this talk please go find a Fostum organizer and send them little shirts and say hey I really like James's talk James Schubin purple idea and if everyone does that will be like a DDoS and it will be really funny and if you don't want to do that that's okay if you go to the schedule link on the Fostum website if you look there's a secret like link right here I didn't know about this for many years called submit feedback so you find my talk you click submit feedback say this was dope it was awesome it was fun if you give me some good advice cost you nothing it would really help deal? just do this like imagine 200 submissions of like awesome they're gonna eventually have me for a main track talk right alright so I have some free stickers there's a sticker cartel so they're incredibly expensive but if you promise to use them on your laptops come at the end out there in the corner I'll give you some away if you'd like and show them to your friends you're gonna have a cool laptop like me and yeah thank you very much before you leave I have probably a few more minutes left for questions maybe someone has questions yes questions this is an encourageable gentleman up here I'm gonna start putting stuff away so I'm out of the way yeah hi thanks for the talk here oh there you are hi like I'm a newbie so sorry if that's a completely absurd question that's been answered like many times before like in the first page of the fact or something but I imagine that the whole dealing with being responsive when you're dealing with stuff that can send you like interrupts and tell you oh I change it's relatively easy but what about like being reactive about stuff that doesn't announce it like newbies starting to write code and then it's suddenly getting MGMT getting 100% CPU just because it's like polling stuff that isn't reactive yeah so the way we work every event source whether the functions that actually look at data or the resources that actually look at changes they all are based on events so select calls I notify her files there's no polling so if there's something we cannot do and we must poll then the solution is to ask the kernel people hey we're missing something there's almost nothing there's a few things left that don't have things and in those cases we could poll but almost everything does have an event system or it's a bug so really good question any more questions got another question over here hi great talk you talked about monitoring does it only work for the system itself or can we use it for our for logging or stuff like that can we replace everything and just rely on the monitoring system I don't if you're leaving try and be a little quiet I don't 100% 100% understand what you're talking about but if you can explain to me better I think you're asking about can we log and do other things besides just automation the answer is yes so this is a general purpose engine for infrastructure automation stuff whether you use it to get sources from events that come from monitoring systems and integrate them into your decisions or not that's up to you for example you could write a Prometheus function from a Prometheus server that was sending data from something else and then respond to those things if you wanted to Patch is welcome for sure we have a space for one more question one more question gentlemen in the front here maybe and come get a sticker if you want yeah mine goes with the first one what's the overhead when you're looking what's the overhead if I'm looking for I don't know 1000 files 100 virtual machines so how painful it is it's incredibly fast so it's probably the fastest tool out there if you were to come to Puppet and all these other equivalents if you had some absurd requirements there actually is a feature called auto grouping which will take multiple resources and group them together so it's more efficient but just one second let me do that this guy really wants a sticker he's like hey so we actually can do some efficient things like that but if you did have something that was totally absurd the fastest are you're probably doing something that might not make sense so I if you find a use case that doesn't work for tell us but I think it's probably going to be good so it's really nice basically it's in Golang it's very fast and yeah thank you so much thank you


In this program, we are going to see how we can find a text by using regex. I am having one PDF file here and it is containing some phone numbers. You will see here, one here, one here, here in the tables and one in the bottom. So basically we are going to have one regex, here it is for the phone numbers and we will see whether we are able to extract all the phone numbers or not. And let me copy it again, copy and paste here, copy always. So our game plan is, first we create the instance of the text extractor, we are going to load the document, we are enabling the regex search, we are waiting through all the pages until we find out and once we find the text, we will display it, so very simple. So let's get started, so I am going to have the one instance of the text extractor and we are passing the traces and key and name here. Let's load the document, load document.fromFile and name is sampleprogram3.pdf. Now enable regex, regex search equal to true. Let us iterate through all the pages, extractor.getPageCount and increment it. Let us see, we are able to find it if extractor.find, we are giving the page index, instead of text we are going to give the regex here and it is gain sensitive and do it until we found everything. So extractor.findNext and let us display everything we found here for each and we are going to have the search result element here, extractor.foundTex.Elements and let us display console.WriteLine and element.Text. Let's see what's output and here it is. So we are able to get all the found numbers by using regex inside the PDF.


Well, first I really want to thank the organizers for the invitation to speak here today and just say it was very hard to find exactly which topic I was going to talk about today because by and large my work deals with modeling how vegetation responds to extreme events. So with this I've looked at how vegetation responds to fires, floods, hurricanes, drought. I wanted to focus on a particularly vulnerable ecosystem these montane cloud forests and their vulnerability to climate change. So we'll focus on that today. And why it's so important is these ecosystems occur at high elevations that typically are the headwater catchments for a lot of our major river basins. There are also hot spots of biodiversity and the forests here are very highly productive. Oh, yeah. And the processes that I'm going to talk about the gaps in our ability to model these systems and how they're going to respond in climate change are not just local to montane cloud forests but really affect forest environments worldwide and particularly forest that occur in mountainous regions. And so forest, 25% of all forests actually occur in mountainous regions as you can see here globally. Now all of these are going to be cloud forest but a large amount of the processes are going to be very similar. And here in my talk today I'm going to focus on two particular cloud forest environments. The first is a temperate cloud forest that occurs in the southern Appalachian mountains and the second is, and so you can see here, you can't see it yet, now you can. This beautiful image of what it looks like to be inside of the cloud forest when you're enveloped in the low cloud and fog immersion. And the second that I'm going to focus on is work that I've just recently started in Costa Rica in Monteverde and this is what it looks like to be in this particular cloud forest. So it's a really nice place to do some field research as long as well as some modeling. So what are some characteristics of cloud forests that make them unique and also challenging to add to our earth system models? The first is this presence of low level cloud and fog. This creates an environment where you have very, very humid microclimates within your canopy. The plants are very well adapted to these humid environments where there's very low ridity. It means that they can sort of consistently exchange gas because they're in this ideal state. Along with this low level cloud and fog, you can see that the quality of light from sun looks a bit different. So you have more diffuse radiation rather than direct radiation and so the plants are also very adapted to this quality of light rather than just the quantity of light that they receive from the sun. The second challenging thing is because you're constantly involved in low level cloud and fog, your leaves tend to be wet. And why this is troubling is that gas can't diffuse through a liquid. And so if you have liquid on the surface of your leaf then theoretically you should not have any gas diffusion. And so this also adds complexity that we're not typically accounting for in our system models. Finally, within these canopies you also get the presence of epiphytes. And so epiphytes are vascular and nonvascular plants. They can look anything from a moss to a small tree or shrub growing on top of your tree in a rather symbiotic fashion. And so these epiphytes also really enjoy the low level cloud and fog just being in this diffuse light environment, this very humid environment and under projected climate change. What we think is going to happen is that you're going to have increasing temperatures in these environments. You're going to have an increase in the cloud base height and we're not exactly sure how that's going to impact how these force environments are adapted to these particular characteristics. And so today I'm going to sort of illuminate some of these gaps and maybe talk through some of the ways that we can improve how we stimulate these processes in cloud forest environments but also any forest environment where these types of processes occur. And so before I really dive in, I need to first talk about two key ways that we incorporate plants into our Earth system models. The first is through some model conductance. Sorry, on our leaves we have these small pores and through those pores is where we exchange gases. So water vapor and CO2 get exchanged through these leaf pores and some model conductance is how we model essentially how open or closed those leaf pores are, how difficult or how easy it is for gases to move between the atmosphere and the leaf pore. And typically how we model this is sort of as an electric circuit where you have a resistance which is the inverse of conductance that moves water vapor through different potentials, water potentials. So water vapor is going to want to move from higher pressure to lower pressure. And so in this particular case it's envisioning this resistor or conductor between the leaf pore, whatever the pore pressure is there, and the atmosphere. The other way that we incorporate it is sort of a bigger circuit model where now we're considering how water moves through the entire plant perhaps all the way from the soils. You could even go down to the groundwater if you have roots that can tap into groundwater up through the stem, the leaves and then out through the atmosphere as transpiration. And so the little conductance term on the side is also accounting for the fact that you can have water storage that your plant can release if it's underwater stress. And so these are modeling water stresses critical for these environments under climate change because we want to know how we're going to change our gas exchange processes and particularly carbon uptake within these regions. And so this was sort of the first question that I had because while we're not necessarily modeling or not a lot of work has been done modeling gas exchange processes in these environments, quite a bit of work has been done through observation and data collection from tree physiologists. And so this is work that was done in the southern Appalachian Mountains observation data. And this has been demonstrated with both field and greenhouse experiments. And so what you see on the left hand side is a plot of photosynthesis under cloud immersed conditions. And you see at 9am and then at 2pm in the afternoon local time. And then on the right hand side is what this, what net photosynthesis looks like at these same times of days, but on a clear day. So when you have no cloud immersion, no low level cloud and fog. And the biggest, the key difference here is that once you get into the middle of the day, through the peak temperature, under the cloud immersed days, you have higher levels of net photosynthesis. Your plants are able to be more efficient at drawing down CO2 from the atmosphere under these cloud immersed conditions. And while it might look like a small amount over the entire growing season, this could be as much as 20% of your overall carbon uptake for these ecosystems. So having cloud immersion is quite crucial to sustaining these forests as carbon sinks. So my first question was, well, how well are we actually able to quantify gas exchange rates in these ecosystems with our current models? With how our current models are simulating gas exchange processes? And so one of the typical empirical models that we use for somatoconductance is called the Jarvis somatoconductance. And it's an empirical model where you're simply simulating your somatoconductance as a series of multiplicative terms where the first is your maximum somatoconductance for that species or canopy. And then you have a series of index functions that represent how your somata want to be open or closed under sunlight conditions. Really, this is only considering the quantity of sunlight, not the quality. So we're not tackling that diffuse light condition. Air temperature, leaf water potential, which again is the water potential within your leaf. It's an indication of your plant water stress, any given moment of time, and then vapor pressure deficit, which is a measure of atmospheric aridity. And so what we wanted to do was use data from the field for these different conditions and what they look like under immersed low cloud and sun conditions. And so what you're seeing are each of these index functions from our Jarvis somatoconductance model in all of these small panels. And you can see they all go from zero to one. And so zero means that gas exchange is not occurring. Your leaf pores are completely closed because the conditions are such that your plant is under too much stress to exchange gas. And then one means that your pore is completely open and you're freely exchanging gas. And so you can see that obviously your plants want to be in low aridity conditions or high relative humidity conditions. So for your leaf to air vapor pressure deficit, when you're close to zero, you're at one. For air temperature, there's sort of an optimum around, I think, 18 degrees Celsius that your plants prefer for keeping their pores open. For the water potential, you want to have lower water potentials and your plant is going to be happier. And then for sunlight, obviously you want more light. And at some point that becomes saturated and you don't get any additional benefit of having more sunlight. And then what you can see in these horizontal bars are showing the ranges that we've seen from observation data experienced under cloud immersion, under low cloud conditions, and then under sunny conditions. And so what we wanted to do was search this entire parameter space and see under any of these conditions that have been observed, if we run them through this model, are we ever able to recreate the gas exchange rates that have also been observed under these conditions? And the answer is no, we actually cannot. And so on the left-hand side are the results from our model. And so this blue is indicating the entire parameter space under all of the conditions possible for cloud immersion. And then on the x-axis, you have your leaf to air vapor pressure deficit and then on the y-axis is the model conductance that we're actually interested in. And on the right-hand side are the results from observation data collected at the site in the Southern Appalachians. And it's a little misleading because the x-axis is not quite the same. But the key is that when we're looking at our cloud immersed conditions, the high end of the range when you're around 0.5 for your leaf to air vapor pressure deficit is somewhere around 0.45 moles per meter squared per second. And if you look over at our model results, you're never there. So we're never able to capture this. And for me, this really points to the fact that we're using an empirical modeling approach and perhaps for these ecosystems, you really need something that's more process-based and explaining how the leaves are actually responding to these conditions rather than just doing this rough approximation that seems to work really well for other environments. And on top of this, if you're using this type of model for your gas exchange rates, well, if you're going to model transpiration, you're also going to be underestimating. And in this case, you're not just underestimating for your immersed conditions, but for all day conditions, both low cloud and sun conditions for these environments. And so this is really pointing to a gap in our ability to actually use our Earth system models to simulate what climate change is going to look like for these environments. So next, I'm going to talk about a new project that recently got funded to look at how local microclimate, but also host tree water status, is impacted by the presence of epiphytes. And so to simulate what we expect to happen with increasing temperatures and increasing cloud-based heights, essentially, we don't expect epiphytes to move to higher elevations with these raising cloud-based heights, because they actually don't move very quickly, is what the biologists have told me. So they expect them to just disappear. And so with some collaborators, they are doing, and they're actually in Costa Rica right now, doing these huge removals where they're stripping the epiphytes from the branches of the trees. And so we'll have some control and some experimental trees, some with and without epiphytes, and we're fully instrumenting them to sort of see how plant water status, but then also how microclimate is changing with this removal. And as a modeler, I'm not in the field, obviously, stripping these trees, but my role is trying to figure out a way to better represent the role that these epiphytes play in our host tree water status and also in microclimate. And so going back to the different ways that we represent our vegetation or our system models, the second approach using a soil plant atmosphere continuum model, that's what we're going to do. And now add to this capacitance term, this plant storage term, this additional storage of water in the canopy because these epiphytes hold a lot of water consistently. And so this additional water term influences water cycling through interception and evapotranspiration from these epiphytes. It influences how much water actually gets down to the soils. And then they also, what's very interesting is that a lot of these trees have roots in their branches that go into the epiphyte maps. So the trees can also directly uptake water through their branches from these epiphytes. And so we're just not sure, and we're hoping with this model to be able to explain and understand how much these contributions of water from epiphytes influence our host trees. And so our approach is to figure out the storage term by using a water balance modeling approach. So we're constructing this epiphyte water balance model where we're considering the epiphytes as a water tank that is held in the suspended in the canopy. And our inputs can come from interception of rainfall and also from fog. So both vertical and horizontal precipitation also do deposition. And then our main outputs are going to be through evapotranspiration from our water tank and also host tree water uptake through those roots that are in the branches. And we have a little idealized simulation running since we don't have our trees play instrumented yet, not able to compare to our data in the field. But we are able to represent the change over say three days and what that water storage looks like using this approach, considering that you have no rainfall input or no fog input. So you can see you have a dry down and the tank is emptying. So I told my grad student working on this project that makes physical sense. So this is a good step. And so these are sort of smaller scale ways to think about how the specific adaptations in these environments are going to influence gas exchange processes. But I also just wanted to highlight and think about some ways this also what else we're missing in our earth system models but at larger spatial scales. And so the first is looking at say regional scales. And this is some earlier work that I did when we first sort of were looking at these Appalachian forests and trying to figure out why our land surface hydrology models were so bad at estimating carbon fluxes over this inner mountain region. And we proposed, well maybe we're just not in our rainfall forcing data capturing the input that you get on foggy base in these systems. And that fog can account for say 0.5 millimeters over three hours in the middle of the day. That's what our fog gauges in this region told us. And so we thought let's just add this to our rainfall forcing and see how much this increases our carbon uptake response. So these are results at four kilometers using a land surface hydrology model where we're physically simulating water budgets, energy budgets, and then using a photosynthesis model that's based on the bar core formulation. And so what you're going to see here, and sorry for the confusing axis, but basically the darker the color, the more carbon assimilation you're getting in the simulation where we've added fog to our rainfall input. Let's see if I can get this going. And this is going to be over the sort of water season or warm season for southern Appalachians. Maybe we're not going to see it. Okay. No worries. Well, if it ran, what you would see is that progressively is you got to the from May to June to July or warmer season months, you would see that this the amount of carbon uptake that you got during the fog simulations increased quite a bit between two to three grams of carbon per meter squared per day, which could be somewhere between 10 to 15 percent of your overall carbon uptake for this ecosystem over its warm season. So that's quite a bit. And so this is proposing, right, so maybe at these larger scales, you don't want to necessarily get into the negrity of modeling some model conductance better or modeling the role that epiphytes play better, but you could get this increase and match better observations just by improving the rainfall data set that you're using for say, making sure that our rainfall data sets are including the rainfall inputs from that we get from fog in these environments where fog is frequent, because here during the warm season, we have foggy days 60 percent of the time. So that's a big water input that we're missing in our rainfall data. So going up even more in scale. And so now we're getting out of just cloud forests or mountain forests, but just thinking of ecosystems where you have wet leaves. And so I mentioned earlier that these this wet leaf problem, I think of it as a problem in our models, but this wet leaf problem really is a bigger problem than just within these montane cloud forests. And so you can see in this figure that a lot of parts of the world have experienced wetting events for most of the days. And currently our models are our system models either completely ignore what it means to have a wet leaf, or others assume that if you have some percentage of wetting in your canopy, then your model conductance is going to get reduced or go to zero, which would be true if we didn't have some model on the bottom of our leaves, which don't get as wet. And so this is sort of a jumping off point for some recent work that was funded with a little seed grant, where we're going to do some tests, actually gathering data on how much gas exchange we get with wet leaves. And then my part is going to be to hopefully first build some empirical models to explain what we're doing and then hopefully get to process based models for explaining how our gas exchange looks like when we have wet leaves, but only partial or no wetting on the bottom of the leaf. And so just to summarize some of these gaps and challenges in modeling plant adaptations to low cloud fog and wedding events. And we're thinking about this at different scales. So the key gaps are first at the leaf scale, getting some model conductance, getting this gas exchange right. And one of the key processes that is also has been observed to occur in these cloud fours that we also don't think about, and might be a solution for thinking about how to build a process based model for some model conductance for these systems is thinking about fuller water uptake. And so this is an adaptation that these leaves have where they're actually able to uptake water through the pores in their leaves. This can improve the water status, which will, you know, through nonlinear feedbacks influence your leaf water potential, and then hopefully increase your your model conductance. That's one way to perhaps close that gap. Next, we talked about at sort of the branch and leaf scale, the role that epiphytes play, and all of the ways that they influence, not just the water budget, but the energy budget by their presence and interception of water, how much gets down into your soils. So really, not just the water and carbon cycle side, but also the energy budget side. At the canopy and plot scale, how this diffuse light and high humidity environment is going to influence your microclimate is a critical need that we're still trying to figure out. And then at these regional scales, this improving our representation of rainfall inputs and an interception of fog water that's not currently being considered, and then an even larger and global scales, this wet leaf issue that we still need to find a better way to deal with. So with that, I want to thank you all for the opportunity to speak and particularly acknowledge my collaborators on the NSF project. That's us in the field in January riding horses, which was really fun. Civil Goach, who's at Franklin Marshall, Nalini, Nicarney, who's at the University of Utah. Todd Dawson, who's at UC Berkeley and missed out on the fun of riding horses, but hopefully next time when we go back this summer, he'll get to join us. In the middle, that's, you know, me with my students and I want to particularly highlight my students who've been working, who've contributed to the work that I presented today, Paul, who's a grad student, and then two undergrads, Haley and Louise, who have been integral to getting this work done. So thank you very much. So I was wondering if you take away or remove those epiphytes because to simulate climate change, right? Would that also change the evaporation and therefore less fog will come in and therefore less water will be there for the tree, actually. And you see kind of it's a spiral, right? So you get less trees and therefore maybe more erosion at some point in the landscape. Can you explain that if that process will occur or not? Yeah. So those are sort of the hypotheses that we listed in our proposal. Some of the, there are a lot of competing effects that we're trying to disentangle with these experiments, but then also with the modeling work. So yes, remove what we, what we hypothesize is that removal of the epiphytes, you're going to have, yes, less evapotransferation from the epiphytes, but instead you're going to get more water that or less water that gets intercepted in the canopy, because now you've removed those epiphytes, but you'll have more water going to the soils. So perhaps the trees will just sort of adapt, that's what we're curious about, whether they're going to adapt to having higher soil moisture and be less reliant on that water storage within the canopy. But also removing the epiphytes in some initial experiments that they did, it seemed to have an impact on that vapor pressure deficit. So basically making it a slightly more arid environment overall. So it's also having this impact on the micro climate itself. So maybe you would get fewer wedding events, so you would collect less water and then your soil moisture would be lower. So we're hoping to disentangle some of these. Hi, very, very nice talk, but also it highlights the difficulty of doing these global upscaling things. But I wonder, in how many of the current global models, is there some sort of representation of these epiphytes? There's no representation of epiphytes in global models. None at all. And do you think it'll change soon? Maybe I'll have a big enough impact, but it will change people's minds. I think that hopefully this work will sort of tell us. And I guess with the work that I do, looking at how we represent vegetation processes, it's not always about, say, building this new component and adding it to these earth system models, but also trying to understand, well, if you don't incorporate this process, what's the size of the uncertainty in your estimate? And also, what are the sort of spatial and temporal scales that it's associated with? Because perhaps, say, epiphyte removal doesn't really matter as much in dry season. It's just in the wet season, these environments, right? And so if you're only interested in dry season processes and maybe incorporating epiphytes isn't necessary for what you're doing. But yeah, so I think the goal is not necessarily to have every vegetation process represented well, but being able to quantify our uncertainty by including or not including these processes.


use results in reduction of SSD lifetime and performance degradation. So the main question, why is it another file system? If trying to consider what we have currently is available file system, it's something like NFS2. It's focused mostly on reliability. F2FS, it's mostly focused on performance. BKSFS focused on reliability and performance. And important, probably the important goal prolongs SSD lifetime. So SSDFS, the first goal is prolongs SSD lifetime. Second goal, it's guarantee strong reliability and finally guarantee stable performance. This is three important goals of SSDFS. So how SSDFS can achieve this? First of all, SSDFS is flash friendly. Open source kernel space file system and goal of prolonging SSD lifetime can be achieved by decreasing write amplification by excluding garbage collector overhead and by means of decreasing retention issue. So write amplification can be decreased by using compression, compaction scheme, delta encoding. Garbage collector overhead can be excluded by means of excluding FTA, garbage collector responsibility by means of minimizing garbage collector activity on file system side. Strong critical reliability can be guaranteed by check-saving support, metadata applications, snapshot support, and stable file system performance can be achieved by means of deploying parallelism of multiple non-dice, excluding garbage collector overhead and minimizing write amplification. So if we take a look at SSDFS architecture, first of all, every SSDFS volume contains a segment, it's a logical concept. It's every segment always located in the same position of the volume and this is guaranteed and this is a way to implement logical extent concept. It means that if we store some logical block into some segment, then this logical block will always located in the same segment, never will be moved in another segment. And this provides a way to not to update, for example, block mapping information and it's one of the important way to decrease write amplification. So there are several types of segments that SSDFS is using and the goal of this to aggregate in the same segment, the same type of metadata or data and to manage this data in more efficient way. So every segment contains one or several logical res blocks and logical res block, it's something like basis for migration scheme, migration stimulation and this is the way how it's possible to eliminate garbage collector overhead. Any logical block can be mapped to any physical res block and this is one of the important point that can provide the way to implement migration scheme and migration stimulation. So finally, every res block contains some number of blocks and every block contain some block mapping of the transition table payload and this provides a way to use compression, compaction scheme and data encoding and this is the way of decreasing write amplification. So first of all, metadata structure of SSDFS start from super blocks, there is special type of segments that contains actual, some sequence of super block states and for every mount and mount operation, it is stored something like actual state of super block. Also additionally, every log contains copy of super block information. So finally, super block is metadata structures that are heavily located between res blocks. So second important metadata structure is mapping table. Mapping table responsibility to map or associate logical res block with physical res block and second important goal to implement migration scheme by means of association to res block inter-migration sequence. Third important metadata structure is segment bitmap. Segment bitmap keeps information about state of every segment and it's easy to find clean segment or dirty segment that can be raised or trimmed or something and it's possible to find for example, there are using state of segment use state of segment, so it's possible to find the segment in different state and this can be used by garbage collector. So next important metadata structure or the rest of metadata structure is represented in the formal B3s. The first is side nodes, B3s that contain side nodes and every node could contain dentists B3 or extends B3 and it's also can be used for example, extended attributes B3. But initially, this is the first time to store some user data or metadata in line without using dentists B3 or some allocate technological blocks if it's not enough space in my nodes and finally it needs to create some B3 or allocate logical blocks for user data. So there are three types of segments for B3 nodes. It's leaf node segment, hybrid node segment, index node segment and the same leaf node segment could contain nodes from different B3s and it means that if we are doing something like flash metadata flash, so updates from different metadata structures will be aggregated into one segment or maybe several ones, but it's something like aggregations that provides a way to manage data or metadata updates in efficient way. So it was used special testing use case scheme. First of all, it was used metadata use case and user data use case. For metadata it was create update delete empty file. For user data it was used create update delete file. It was used several sizes of files, 64, 16K, 100K. For assess deficit was used also three sizes of race blocks, 128 kilobytes, 512 kilobytes, 8 megabytes and finally it was used multiple mount and mount scheme. It means that for example if you need to create something like 100 or 1000 or 10,000 files, the whole operation was split on some number of iterations and during one creation we create 10 files, 100 or 1000 files and multiple mount and mount approach was used to guarantee that file system cannot hide something called all, for example dirty metadata, dirty user data will be flushed and you can see the total number of read IO request and write IO request without any hidden sample. So it was used, it was tested all these use cases but currently I'm ready to share only create empty file use case. So about methodology, first of all the first goal of SSDFS prolonged SSD lifetime. So it needs to suggest some scheme of estimation, a lifetime of SSD device because if you can compare for example how long can be lifetime for one file system, we can compare with another one and then we can make conclusion can some file system prolonged lifetime or not. So first of all, we need to use something like raise a limit because in the SSD contains some number for this block, some capacity and maybe raise block as a limit for raise operation. So finally multiplication of capacity or this limit can provide some raise limit for the whole SSD. Next we need to estimate how many raise operation can use case generate some total number of raise operation and if we divide limit on total number of raise operation for some use case, we can calculate for example how many times some use case can be repeated for this file system. And if some file system can repeat the same use case more times, so it means that file system can prolong SSD lifetime more. So if we are talking about total number of raise operations so we need to take into account how many raise operation can generate less translation layer for example garbage collector of FTA how many trim operation can initiate file system how many operation can generate garbage collector of file system side, read disturbance could also generate some raise operations and retention issue could also needs in some raise operation. So if you are talking about FTA and GC so it means that we need to estimate amount of in place updates because calling place updates it will be responsibility of for less translation layer. We can estimate this as difference between the total number of right file request and payload. What is payload? It's something like some unique number of raise blocks minus same operation. So something like some number of raise block that was updated during the whole use case minus in place updates. So we can estimate garbage collector activity by means of for example difference between payload size and really data size. It's of course it's something like not exactly accurate estimation it's something like more upper bound estimation because first of all it's not so easy to estimate the data amount because file system using different techniques but it's possible to make some assumption and for example this difference can show for example potential activity of garbage collector because it's possible to imagine that every valid block that was invalidated during update operations could be located in the same place block that contains another valid data in something like worst case or this valid data needs to be moved. So finally it's potentially can generate some significant amount of activity. So read disturbance can be estimated like division the whole total number of read operation on some threshold. Retention issue can be estimated like a division duration of use case on three months duration and multiplication this portion of time on payload size. So we have pretty reading methodology to estimate for example SSD lifetime. So first of all take a look at the right request case. So SSDFS is using compaction scheme, compression is using data encoding. So but in for the case of for this testing that they call delta encoding hasn't been used. So usually it was used mostly compression and compaction scheme and this is the way how SSDFS can decrease right amplification decrease some amount of right request. It's possible to see that SSDFS behaves in a pretty efficient way and mostly on the NLFS tool can compete with SSDFS but mostly for something like 10,000 or 100,000 use cases because in this case especially for big areas blocks, SSDFS can generate significant number of partial blocks and it means that it could be created significant amount of additional metadata. But first of all delta encoding hasn't been used and another point that usually if you're talking about 10 or 10,000 it means that we are using multiple mount and mount operations that it's not a real life use case. For real life use case we never do such significant amount of mount operations. So for real life use cases SSDFS looks better even for NLFS tool case. And especially for because country talking about metadata especially for user data I expecting SSDFS looks much better than NLFS tool. So SSDFS is using migration scheme and migration stimulation technique. This is the main way to exclude garbage collector overhead and one of the evidence of this is the amount of claim operations because they come here namely pressure of regular requests in migration scheme and migration stimulation do the main activity for moving valid data for exhausted there is block interclean one. And it's possible to see that this technique is pretty efficient because for example it's techniques provide opportunity to train to raise all invalidated. First of all, alter is blocked can be validated efficiently. In second point, if it's completely validated migration scheme, migration is finished. Then this is blocked can be restored or trained and it's possible to see that this technique works pretty efficiently. So why this technique doesn't work for some use cases. It's because for example if you talk about eight megabyte of this block so the amount of operation is not enough to finish or even start migrations. So in this case, dream doesn't happen. The same for example, for some use cases for smaller is blocks. It means that for example it was not enough operations to finish migration. And this is why I'm using for example multiple mount and mount approach because namely this way provides a way to see how for example, dream policy is working not wait a long time because for example namely multiple mount and mount operation provides a way to see that this policy can work efficiently and especially it's possible to see that for example even multiple mount and mount operation cannot affect dream policy. This policy can work efficiently. I believe that it's not so for it to be fast enough because for this case a garbage collector can be affected by so short for example time of mount operation. So this is I think a pretty good point. So if you would like to consider payload. So first of all again, this is DFS is using compression compaction scheme and this is first point to initiate smaller number of writer requested. Meaning that we store smaller amount of metadata or user data for example. But second point, second player in payload it's something like dream policy. And for example, if this compaction scheme compression plus dream policy works together. So finally we can see that SDSDF is capable to create smaller payload. And we can see that SDSDF can generate bigger payload for some use cases because dream policy doesn't work for this use cases because it was not enough operations of right operation to start to finish migration summary blocks. So, but in average SDSDF is mostly looks much better as a file system and mostly for in most use cases it could create smaller payload. So especially for real life use case because it was used something like multiple mount and mount operations. And for this case, SDSDF could be not so efficient but it's not a real life use case. In for example, for smaller, there is blocks for example, SDSDF could work much better. But again, it depends from use case. It depends from environment and so on. So for estimate SDSD lifetime, we need to estimate FTL garbage collector activity. And first of all, SDSDF doesn't create this responsibility of FTL garbage collector FTL because it's pure LFS file system. But for example, for LF2FS or LFS2 another file system create with responsibility and it's possible to see that LF2FS creates pretty significant responsibilities or necessity for many situations on a tele-site. And LFS2, LFS2 because it has a place of data and LFS has two super block and the begin and end volume and the end and close volume and this super block updates in place so it's also created some responsibility. So FTL, LFS2 has garbage collector LFS site and this is something like try to estimate upper bound of possible overhead or possible operations that garbage collector LFS site can generate. It's not completely accurate data because it's possible to say that this estimation between zero and this upper bound, I think that potentially the real overhead could be between these two lower bound and upper bound but it's something like potential upper bound of this possible operational garbage collector site. It's impossible to see that LFS generate significant amount or generate significant amount of garbage collector activity but again, F2FS and LFS2 using such policies that garbage collector start to work until, though it doesn't work until achieving some threshold. So finally it's create some retention issue. So if we consider right amplification, so how we can estimate decreasing right amplification? For example, we have numbers for right request. We can add to this number estimation of garbage collector overhead on the system side mostly for LFS2 LFS2 LFS. And for SSDFS case, we can do the same but for SSDFS no garbage collector by request. So we can for example, divide total number of high request right plus garbage collector and divide on right amount of right request for SSDFS. And in this case, we can see right amplification ratio and we can estimate how SSDFS can decrease right amplification ratio. And it's possible to see that SSDFS can decrease right amplification significant even lower bound really looks pretty good. But if we consider, but this lower bound usually for multiple mount operations or it's for real life use cases this number should be and it's possible to see that even now that it's pretty better than the other four systems. So if we take a look into read our request, so in this case, because SSDFS it's log strike full system at least logs and there is some price for this because in this case it needs to use, it needs to read slightly more or read more than other full system can do. So SSDFS looks better like new FS2. It's looks comparatively same like XFS, but currently SSDFS generates bigger amount of return request and sometimes for big risk logs it can affect currently performance. And the main contributor to this it's offset transition table. So currently offset transferable health is some issue because currently this table distributed within multiple logs. And if you would like to build a set transition table for some risk block or for some segment it needs to read all more logs, to check all logs for presence actual state of portions of offset transition table. As a result, it's create a lot of return requests for some use cases, but there is solution. It's possible to store full offset transition table in every log to use compression to store this transition table in compact manner. And it's possible to achieve bigger improvement for this and it can decrease number of return requests. And also it's possible to use binary search to find latest log. So there is a way to decrease number of return requests and it's a pretty interesting way how SSDFS can be improved. So retention estimation shows that for example, SSDFS looks better for mostly for all use cases, but for some use cases it's possible to see that it looks like not so good, but there is interesting point here because when I'm trying to estimate retention issue, I'm using, for example, time, I'm using duration of use case. But for some use cases, for example, 10,000, so it's multiple mount and mount operations, it creates a lot of partial logs and it's create a lot of read operations. And finally, read operations effect or make duration of use case longer and it's create, for example, bigger retention issue estimation. So if, for example, offset transition table, issue is this, offset transition table will be solved. In this case, it decrease amount of return request, it improve situation with duration of some use cases and retention issue will be smaller. And in this case for all file system, SSDFS will be better compared with all file systems. So finally, we can combine all the numbers, we can combine all the estimations in the final number that can show, for example, how SSDFS can prolong SSD lifetime. So some use cases doesn't provide good numbers for this estimation because for some use cases, retention issue estimation and read disturbance estimation define the number for SSD lifetime. And this number mostly makes SSDFS better but better significant amount of time. So I decided not to use these numbers, I decided to use the most reliable numbers. And this number shows that as minimum SSDFS can provide SSD lifetime two times for real life use cases, even for even lower bound, really showing that, for example, compared with this X4 and 2FS, it could be one time, one point four times bigger SSD lifetime. But in real life, it will be significantly bigger. So it's possible to see that SSDFS can prolong lifetime of SSD. So it's possible to see that mostly for some use cases, for example, if we have a smaller number of mount and mount operation in this case, SSD has pretty the same comparable duration with other whole system. But as I mentioned already for the case of, for example, multiple mini mount and mount operations, something like 10 on 10,000 case. In this case, SSDFS needs to read a lot. And in this case, this affects performance or read path effects SSDFS performance. So it's possible to see that because it's log-based file system, SSDFS using blocks. And finally, this is a price that it needs to read multiple information, a lot of information from blocks. And finally, SSDFS looks like read domain. However, it needs to mention that first of all, SSDFS has been tested in debug mode. It means that it was used debug messages and it also increase, for example, duration of some use cases. SSDFS still has not fully optimized code. But even now, SSDFS performance not comparable with our whole systems. But if the problem, the issue with offset transition table will be solved, then situation can be significantly improved. Because if we can generate smaller amount of right request, so it means that we can be faster. The problem currently seems to be because SSDFS generate a lot of right request and it's possible to solve this issue by means of solving problem with offset transition table. Then numbers will be significantly better. So another question, is SSDFS solving SSD rate? So from architectural point of view, yes, it's completely ready because first of all, it's pure log-stract file system. It's possible to use logical release block equal in size to zone. So from architectural point of view, no troubles. But from the implementation state, it needs to make some implementation efforts to fully support zone namespaces SSD. Especially because it's possible to have something like an aligned zone size. It's possible to have a limited number of open active right pointers. So in this case, it needs to use slightly more smart technique for SSDFS. It's not big trouble, but it requires some implementation efforts. So the rest is pretty no troubles at all. And it needs to solve problem with offset transition table and everything looks pretty good from one point of view. So what's about future work? First of all, because I shared only create and defile case, it needs to process as a rest of benchmarking results and to share information or results for update, delete, case for metadata and for user data. So to prove that for other cases, SSDFS works better too. It needs to fix issue with set transition table. Of course, there are bugs in current implementation. It needs to fix these bugs. It needs to, for example, to make some implementation to support zone namespaces SSD. It needs to finish snapshot support because it's implementation is functionality duplication support, it's entertainment implementation. It needs to finish recovery first implementation and assistant chair utility implementation. So this is about future work. As a conclusion, it's possible to see that SSDFS can generate smaller amount of right request and this is the way to decrease right application issue. SSDFS introduce highly efficient new policy and this is the way to decrease retention issue. SSDFS is capable to create smaller payload. Again, it depends from race block size and depends from use case. There's a amount of right request and so on, but it can be smaller because of compaction, compression, delta encoding and efficient trim policy. So SSDFS doesn't create FTA which create the responsibility because it's pure extract file system without any place of data. And this is also creating zone namespaces D compatible. So SSDFS mostly doesn't create garbage collector right request because of migration scheme and efficient trim policy. There is only one use case that garbage collector need to participate if for example, to race block stuck in migration because for example, some data could be called or maybe warm and migration could start but for example, no enough right request to finish migration in this case, garbage collector can help. So we can see that SSDFS decrease right application. SSDFS capable introduce smaller retention issue. And finally, SSDFS can promote SSD lifetime as minimum two times, but I think that could be real. It's possible to say that SSDFS can promote lifetime more for example, 10 times, but again, it depends from use case. It depends for example, what file system we compare and so on, but I believe that SSDFS even now looks pretty good and can show pretty good numbers. So it's everything that I have now. Thank you all for attending this talk.


Good morning. Today we have, well, Brit has a prenatal appointment. I'm going along with her. I've had to miss the last couple, so I gotta be here for this one. You ready? Well, once I've de-shedded. What are we all supposed to be learning at this appointment? This will be the day that we, I'm getting an exam to determine whether or not I need a C-section, but all signs point to yes, unfortunately, but what can you do? That's right. My baby's okay, and I wanna ask about hospital tours and stuff, and ask if I still get a maternity suite, even though I'm a surgical patient. I've heard that some people haven't gotten one in this town if they got a C-section, which I don't find right, but yeah, ask all the annoying questions of the doctor that you probably won't know. Okay, but the big thing is we gotta find out today if it's gonna be a C-section or not. Yes. And if it's a C-section, what I've learned from Britt is that then the baby is delivered a week early. If not earlier. Which means that it would then be delivered around March 25th instead of its due date on April 1st. So. You might not get to share a birthday, but that's okay, as long as the baby's healthy. I'm thinking more so along the lines of my time off, because my time off, I've booked off since March 17th, or on March 17th, which is Friday, which would only give me one week to make sure everything is ready before the baby comes in instead of two. No pressure. But at least then with a C-section, you know when the baby's coming. Well, you hope. Like you know pretty much down to the day, down to the hour almost. Unless you're my cousin Ashley, and then you go into labor a week before your C-section anyway. Well, don't do that. I'll do that. I'm gonna start confusing work if I have to keep changing it. We don't know what we're doing. It's our first baby, if you're new. It's our first one. We've been trying for a very long time. Five and a half years. Five and a half years. This was an IVF baby. So we went through, she went through a lot. Oh, we went through it together. We, let's say we. It's a big thing. It's a big thing for us. So we're excited. We're gonna go talk to the doctor now and learn some more. Geez, we got back. We came back. So it was a good appointment, I think. Yeah, got a lot of information. Mm-hmm. We have officially made the decision to have a C-section. Well, I made the decision. Josh supported it. It was really up to us. We had three options. And I decided that in my gut, I felt like a C-section was the safest option. So it's not ideal. It's not my birthing dream, but that's okay. It's okay as long as the kid's okay. That's what matters. So that means that the baby will be here before it's due date on April 1st. Yeah, no shared birthday, but that's okay. Still special that the due date was April 1st. Mm-hmm. So it'll be, we're expecting, we don't know the exact date yet. We have to go and talk, have a meeting with the surgeon and figure out an exact date when they wanna book it in. That could change as well also. Like you said before, your cousin had an early one. Yeah, exactly. Yeah, so a week or two before the due date, I guess, between that timeline. Around March 25th or something, but at least we'll know the day where it will be no later than this day at this time. We just have to figure out what day that is. Yeah. But everything else looked good, right? Yeah. Healthy baby. Baby's heart rate's still 150 or above. 150 to 153, I think something like that. But yeah, everything was good. Belly size is still pretty normal. Yeah, not gaining a lot of weight, so that's good. Baby needs to gain weight, I don't need to gain weight. So yeah, everything's going really, really well and our doctor's still amazing and has the most soothing voice in the entire world. It's true. Human value in that man. Just he walks into the room and he starts talking and everybody's anxiety is just, he has a voice. He's a really good doctor. He's good at what he does. I'm sure he doesn't talk like that all the time. We were talking about that too. If he did, he'd be the most relaxing human to live with. I just fall asleep all the time. The only other concern that we had was my blood pressure was really, really high. They took it four or five times and it was significantly higher. So we do have a blood pressure cuff at home so now I gotta take my blood pressure every day. Yeah, and write it down for him and I'll see him in I think six or seven days from now. So now it's every week until? No, it's every second week until March hits. It's just that he's not there the week after so I had to make my appointment sooner. Which works out fine for the blood pressure results so. Okay. So it's a good appointment. That's that. Nice to meet you, heart. So on to another topic, diesel. A couple of days ago I mentioned at the end of my vlog that diesel's been having a lot of anxiety problems and panic attacks in the truck as he's gotten older. The first time I noticed it was years ago when we crossed the ferry to Newfoundland in Canada. It's an eight hour ferry ride and he has to wait in the truck while I'm upstairs and when I got back he was having, he had a little bit of a panic attacks or shaking and clinging to my side and there wasn't anything I could do to console him or bring his anxiety down. It just had to wait for it to pass. And then it didn't really happen much but lately as he's come on the road with me any abnormal noises like if I go down a gravel road in summertime or if I hit rumble strips when sometimes they're on the center line or right on the line. If the truck just goes to those rumble strips just once he starts shaking a little bit and the noise of the truck. So he's been having some anxiety problems. So he's been mostly retired here at home at home but we're gonna try something diesel. We got you a gift. We got you something that might help. It's called a thunder shirt. And this is for dog anxiety. It's great for fireworks, thunderstorms, separation anxiety, car and air travel, leash pulling, barking, licking and more. And that's what it looks like. And it pretty much gives them pressure around their torso that comforts them. So we're gonna give it a shot and see if it helps them. He's a diesel. So it recommends in the instructions to first present it to him for the first time as a plate to put treats on it. So that he associates it with something positive. Yes. That's a lot of treats. Oh, lucky boy. Diesel, come. Diesel. Come on in. I got something for you. One second, I'll tell you, that's a fancy plate for you. One second. Okay, you see this? Look, we're gonna come over here where mom can see. Oh, oh, everyone.  He's a look. Hey, hey, look, over here. Oh, oh, now you see him.  Boy, oh, some of your favorites, right? Some zoops. It's a good thing. Okay. So, come here, Diesel. I'm gonna put this on you like this. We've got the other boys locked up just for now so that we can do this as stress-free as possible. Yeah, so we don't trigger his anxiety before this thing's even on and associated with something bad. That one like that. And this goes around here. Diesel. Diesel, you wanna spin around so they can see what I'm doing on this side? Diesel, come here. No. Nope. Well, it's Velcro on this side. Goes under, wraps up in here like this, and then this flap goes over that like that. Oh. Wow. Thundershirt.  So sporty. Do you feel relaxed? Did you wrap it tight enough? Has to be like a firm hug. Not a tight hug. Don't hurt his belly, but a firm hug. It's pretty stretchy materials. Yeah. Do you have any circulation? No. That's pretty good. All right. How, Ezel? Is it diesel? You look so good, so handsome. What do you think? Wow, what a good boy. Does it feel calming? Show starting. So we're gonna try this in the truck with him and see if it helps. What do you think? Come here, go outside. It's supposed to help with barking. It was only two barks, so it wasn't bad. Not bad, he didn't cry after.  See what they think of your new outfit? They're gonna be so jealous. You're gonna have to take it. All right, weaner. Did he get a new shirt? I need one too. You don't need one. Damn, we're... You just got a bag of $70 food. Yeah. We'll see if this helps you. It's like getting a big hug all the time. We just switched over Frankie's food to a neuro care food because he's got dementia and he was sundowning really, really bad for those of you who don't know what sundowning is. Humans do it too with dementia and Alzheimer's. It's very common for them to get confused once the sun starts to go down and Frankie was walking in circles, he was confused, he was crying. He was taking Christmas ornaments off the tree. It was just, he wasn't himself. I could tell something was wrong and he is old. We don't know how old but he is older. So we decided to try out a recommended Purina pro plan neuro care kibble for him and we got a free bag from the vet and then today we went and picked up the second bag and it was like 67, 73 I think is the exact amount after tax for a six pound bag of food. This right here. Yeah, there she is. You guys are expensive. So expensive. But they're the healthiest seniors in town. That's right. So yeah, I mean thankfully he's a little guy. He's less than 20 pounds. So he doesn't take a lot to feed but I have, I don't know if it's just placebo effect on me or not but I have noticed a lot of improvement. He seems to be a lot less confused and crying a lot less. He's clingy or lately but I think he's just picking up on that from Wiener because he takes a lot of cues from Wiener.  Ice shabby. Frankie, you want attention from your dad? Hey big guy. Time to get back to work. We got the throne all set up. Plush blankets, soft, comfortable. You know what that means? You've got the weasel in his thunder shirt. I'm just under weasel. I'm so relaxed right now guys. You don't even, you don't even know. So relaxed. This thing is awesome. This is my thunder shirt. I'm my thunder weasel. And I just wanna sleep. It's so nice. I've never been so stressed free in my life. You do look pretty relaxed, Diesel. You think it's gonna help? We're gonna give it a shot. We're not going far, okay? Just gonna go to the paw. And a couple other short runs. We'll be home in a couple of days, okay? You definitely do look like you're pretty relaxed. Hope it's working. I guess I could have looked at the forecast before I left. That is my bad. That is unlike me. But it's a cold one today. Cab there just walked him. He's keeping warm. I don't know if you can see him. Probably too dark. He's in the passenger seat right there. It is minus 31 outside Celsius. You're wondering what that is Fahrenheit, it's cold. We're gonna sleep right here on this wonderful lot because our facility is right behind over there. The big office and everything and there's a driver's lounge. So if my truck suddenly decides to quit running, I have some more warm diesel and I can go. You can see diesel in the back window here now. Some money. First thing in the morning, I've gotta go get loaded.  This whole week is gonna be like this about minus 30 at night and about minus 25 during the day. What is what it is part of the job up here. This is our home and we can take it. We don't mind the cold. Well, we'd rather not have the cold. But you know what? We'll deal with it. I've got old blues grill cover all buttoned up for the night. If this engine is warm as possible. I've got my fuel tanks full of fuel. Keep warm in these cold temperatures. Some people ask how do you live in these cold temperatures? The only reason you're here in Manitoba is because you wanna work. That's the only reason anybody ever moved here is you wanna work. And that's the only way to keep warm. You gotta work. You gotta keep moving. As soon as you stop, you freeze.  You go, go, go, go, go.  You gotta work hard. You gotta keep going. You gotta keep things moving. Doesn't matter what the temperature is outside. Doesn't matter if it's snowing, raining. If the sun is shining, if it's 100 degrees Fahrenheit or if it's minus 40, you keep going and you keep working. And that's the attitude of everybody who moves here. Because there's no other reason to be here. If there wasn't money to be made here, believe me, everybody here would be gone. Money, the great uniter. No matter where you come from, you wanna make some money? Here's the catch. It's in Manitoba. It's too much for a lot of people and they just go, nope. And they go straight to Toronto or straight to Vancouver. That's fine.  You guys aren't tough enough. Fine, Toronto and Vancouver for you.  I'm not even joking. You gotta be tough to be on the prairies. You have to deal with extreme heat in the summertime, extreme mosquitoes and bugs. Sorry, my mustache is itching me right here and wintertime is cold, so we get the extreme of everything. But you know what, it's home and I love it. And I wouldn't trade it for anything and I will defend it with everything in me on its own. Diesel, how'd you like your thunder shirt today? I know the lighting's not the greatest in here. I took it off, it's right here. How'd you like, it actually seemed to really help him. Like honestly, I can't really make an assessment based off one day or one evening with like not even 100 kilometers or 60 miles behind us. Lots of see how it goes through this whole trip. But it seemed to keep him calm. You know, the roads are pretty rough right now because it's so cold. Any moisture that's like seeped into any of the cracks on the road is all expanding, like freezing and expanding right now. So it makes the roads really rough at this time of year. So the road, truck was bouncing around as we were bobdailing to the yard here. And he had his thunder shirt on and he seemed to be doing just fine. Seemed to just be relaxing, just chillin' in the back. Once we got here, I took it off of him. What do you think, Diesel?  I hope so, cause I really wanna take him with on more trips. The shirt is supposed to be like, it's supposed to be like a big hug, right? So when he's feeling stressed out or, you know, a little bit nervous, the shirt's supposed to make him feel like he's, you know, nice and cozy, getting a nice hug. And studies have shown that it really does help. I will let you know if it works or not. The brand is Thunder Shirt, I believe that's what it's called. I showed it to you before. If you wanna try it on your dogs after you see how Diesel works on it. I'm not sponsored by them or anything. I don't know the owners, I've never talked to them. This is just something that I bought myself. This is actually a recommendation from my wife, Britt. She's the one that said that we should get this for Diesel like years ago already. Thunder Shirt, that's the brand for dog anxiety. It's great for fireworks, thunderstorms, separation anxiety, car and air travel, leash pulling, barking and licking and more. 100% satisfaction guarantee. Well, there you have it. 100%. What does it say on the back here? Let me read this to you. I find this fascinating. It says here, how it works. The Thunder Shirt's patented design applies gentle constant pressure on a dog's torso. And this pressure has an amazing calming effect for most dogs. Used for symptoms including panting, shaking, drooling, barking, whining, hiding, scratching, licking, bolting, eliminating indoors and more. Yeah, that's what happened with Diesel. When he had his little bit of panic attacks, he would just sit beside me and shake, which was strange, right? Cause he grew up in the truck with me. This is all he knows. He knows what's going on. He knows where we are.   But, you know, something in here, he's started having anxiety in his older age. So, here it says, feels like a hug. It says, pressure has been used to successfully reduce anxiety for many years for both animals and humans. Examples include parents swaddling infants, veterinarians using squeeze shoots when vaccinating cattle, and people with autism using pressure to relieve persistent anxiety. So, I'm not doing an ad for them, but I'll let you know how it goes. Just like I always say, I only talk about products with you that work for me and that I actually use myself. And if I haven't come to a conclusion yet, I'll let you know. Just like this, we were just trying to stay for the first time. So, thanks for joining us today, guys. It was very nice and very exciting to be back. The weasel is back. Guess who's back? It's me, it's Weasel. Can you go do some trucking? Guys, Sunday Weasel here, Sunday shirt. You ain't good. I'm an old man now.  So old, so old. You give me, I'm so old and wise, I can sense it. Sure, you bet. You are pretty smart, that's for sure. And I am happy to have you back in the truck with me. I hope that this really works out. It's not the same without you, bud. I don't like trucking without my weasel. And they've all been asking about you. They've been missing you. And I told them you're relaxing at home enjoying the semi-retirement. Don't touch my posh. Don't touch it, just seeing I don't like the most. Okay? Like this, bud? Yeah, so don't touch my posh. A little crumpy? He's never liked it when I touched his posh. So, hit that subscribe button. Tomorrow we'll be trucking and it's gonna be cold. So, I hope you tune in to keep me warm by clicking the like button. It helps keep me warm. So, right now go down below the video, click the like button. And if you really wanna send me a cup of hot chocolate or something, hit that subscribe button and the bell. And what will feel like a wave of warmth will wash over me and keep me from freezing solid and I won't die. So, I appreciate it. We'll see you in tomorrow's video.