Live from Las Vegas, Nevada, it's theCUBE covering EMCworld 2015. Brought to you by EMC, Brocade and VCE. Welcome back to theCUBE. theCUBE has been called ESP. Live continuous coverage from EMCworld 2015 here in Las Vegas. I'm Stu Miniman, joined by co-host Steve Chambers. We're with Wikibon. Find all of our research on wikibon.com. Having a regular back on theCUBE. Jack Rendoni, who is the VP of Storage Networking. Of course, talking storage ready EMCworld. Jack, welcome back. Thank you. It's great to be here, Stu. I'm glad to see I'm a regular now. That's awesome. Absolutely. I'm moving up in the world. We're going to take a little bit of a different interview with you this time. We've talked a lot about traditionally storage networking. Many people equate to Fiber Channel. That's right. And of course, Brocade's the industry's leader in Fiber Channel. Fiber Channel's doing great. We're going to kind of put that aside for this interview and talk a little bit about the IP networking to start with some of the flash storage that's doing there. So introduce us to what is IP storage networking? I mean, isn't IP just IP? Yeah. So that is the question, right? Because for the last 15 years, that was the story, right? And you hit the nail on the head in the sense that I was in the past, the last 10, 15 years, if you had something that was important, you put it on Fiber Channel. We're going to stay in Fiber Channel. It's going to continue to go along. We're all happy about that. But then what we've seen, and then when it wasn't really that important, you put on your IP storage, right? And think of it as like really mission critical type of work loads. You put it on Fiber, if it's file sharing or something, you can get to it in two or three days. Yeah, you put it on IP, whatever, right? And thus, the network didn't matter because the workload didn't matter. So the change now, what we're seeing, Stu, more and more, is that people are putting high-scale VM stores, they're putting analytics, and those are workloads that are being driven apps that are purely for IP types of storage. So what we're seeing more and more with our customer base is as they deploy these important workloads on IP level storage, they're asking more and more questions about the network. They're starting to realize that the network actually does play a role in terms of the overall level of reliability, performance of the environment. So Jackie, I mean, I lived through this for many years.  Yeah. And one of the challenges was if I needed performance, and I went to the network team, it was a three-letter word that was a four-letter word, it was QOS. Oh my God, no, I don't have time to adjust that. I'm just general purpose network and I'm not going to take care of that. So the storage people said, forget it, if you're not going to take care of it, I'll just own it, and therefore the storage network was kind of there. And that exact same dynamic we see happening in the sense that QOS is still a bit of a four-letter word. And when the storage buyers are buying these new arrays, new systems, we're in these workloads, what we're doing as part of our strategy is saying, well, let's give them an IP network that feels like a, it performs like a simple, high-performance storage network. In fact, we're designing features and capabilities that are specifically designated for a storage person to the point where our Ethernet fabric switch, called the VDX6740, has been branded by EMC. And it's positioned by EMC as an IP storage switch. And so the idea then is that dynamic that you're talking about, complexity, politics, whatever it is, you basically give the storage buyer the ability to go, deliver on the SLAs that they're going to be held accountable to and do it within an environment that they don't have to learn protocol exotica. Like if you ever look at Ethernet data sheet, and we make big, beautiful Ethernet switches, so don't get me wrong. But Ethernet needs to do so much. Fiber channel is relatively simple because that's really all it does. And so our IP storage... I'm sorry, Jackie, did you just say that Fiber channel is pretty simple? Relatively speaking, absolutely. I mean, how do you answer the question? I mean, we're not going to talk about Fiber channel, but the general commentary in the industry is that Fiber channel is this dark art that storage people do. It's not like, oh, well, Ethernet's simple. Ethernet's everywhere. It's ubiquitous. Is that just not true? If you want to do a couple ports at five terabytes, you can do whatever you want. But you want to be a petabyte scale, complexity, and variance leads to stability issues, leads to all these problems. Fiber channel from a protocol perspective is very, very lightweight just because it has a single purpose, really. Steve, do you want to chime in on any of that? What's your thoughts?  Yeah? We've been talking today about performance and, you know, immediately you think IOPS and things like that, but increasingly we've heard from customers today that performance for them is the time it takes them to actually get something done. Absolutely. And I think once Fiber channel's in place, then, yeah, I get it. But I think what Steve's referring to is, you know, I think there's an impression that Ethernet is completely different. You just plug it in and away you go. But I think you're saying there's a little bit more. You know, it is. And I think, again, when the workloads are important, you're doing it high performance and high scale. The network matters. Fundamentally. I mean, the network does matter. And what we're doing then is with our Ethernet fabric technology, is building the feature sets, right? So you maintain that level of agility that you'd expect from Ethernet, but then you get the performance and the scale of some of the automation that you'd expect, right? Specifically for storage types of workloads. And we're seeing good traction in the market with this. You know, EMC as a partner, you know, they're branding it. Connectrix IP switch, or IP storage switch. And so we're very excited about that in terms of our position within the market to not only build upon our Fiber channel heritage, but address file-based solutions. Even based, you know, object, right? You know, some large object clusters we're looking at, as well as even hyper-converged infrastructure type of solutions there, right? So you get to a larger scale, the network starts playing a more and more important role. So it's very exciting for us. And by the way, the way we're attacking this too, I'm Steve, it's not just a single product. So we're coming in with a, we announced last week a disaster recovery business continuity solution qualified for large scale IP storage environment, right? We already did that in Fiber for years. We're doing it for IP today, right? We're doing it within our management software, right? So we have a single management interface, broken network advisor, whether it's Fiber channel or IP, gives the customer data and information for a storage professional to make important decisions about their storage network. So what you're saying is, you know, right at the top, you were saying that, you know, in the olden days, if you like, you would prejudice your workload on to Fiber channel if it was really important, less important. But I think what you're saying now is, if it's a really important workload, you're still getting all these great enterprise features on Ethernet as well. Exactly, exactly. And in fact, the matter is, you guys are right, a lot of the new workloads are being put on Ethernet, right? And so, and they expect levels of performance and reliability, right? And that's what we're delivering with our IP storage solutions. So, Jack, you know, one thing I want you to dig in here for a second is, you know, it sounds like when we're doing an IP storage network, it's not a general purpose network. It's something that's going to be used, you know, dedicated to that environment. So, in many ways, it's going to look like a Fiber channel network. You know, what I want you to kind of address there is, you know, does that defeat some of the purpose of going to, you know, an IP network?  You know, utilization is still, you know, really low for most equipment in the data center. Can you kind of address that challenge? Yeah, so I think, you know, a number of companies, so just put brocade aside, right? There's about, you know, 10, 15 companies that we've seen out there, device manufactured, workload that say, basically, if you're running certain levels of scale in I.O. that a dedicated IP network is the best practice. So it is the best practice in the industry. We've talked to analysts, we've talked to big customers, like, we've been doing that for a long time, right? Yeah, absolutely. And I study that was, like, the way we did it going forward. Absolutely. But we can't get beyond that. It's, you know, architecturally, there's not something that we can do. So, no, no, so we're there, right? So you say, now, once you're separate, then the question is, is what does that network look like, right? Does it need to be a, you know, if it's for VPLS, MPLS, and broadcast, multicast, you know, all these types of things? Absolutely. I mean, there's a number of those capabilities within our VDX that needs and switches needs and that switch. But what we're adding onto that are specific storage-related capabilities, right? And FabricVision, for example, is a deep instrumentation level of service that we brought in the Fiber Channel. We're bringing that over to our IP network. The only people that are going to appreciate that are actually storage people, right? Really what it comes down to. So, yeah, it's an ethernet switch. It'll do your ethernet, you know, course stuff. But then the built-in multi-path and the built-in management, you know, we think has a special appeal for storage professionals. So, you know, we saw a really interesting keynote this morning, you know, the beast was unleashed today, right? Yeah. And the performance figures were astounding, and we've heard from some customers today that it just changes the whole equation for them. Yeah. You know, I think Stu's already said to a few people his performance no longer, he's no longer, it just takes it off the table, right? Yeah. But one of the things that stood out to me this morning when we saw the keynote was, you know, you need to keep feeding the beast. And I think, well, if you've sold performance there and this thing is so hungry for data, then is it going to change your network architecture to get to it? Or can you just plug it into the same old thing you had?  Do you see a different architecture required to have an old flash array at the end? Do you know how does it affect you guys? Yeah. So, for us on the Fiber side, so most of the connections we've seen coming out of the all flash arrays have been fiber channel. Right. And, you know, our fiber channel products are very low latency. We measure in hundreds of nanoseconds type of stuff. So it's really, those are kind of peas in a pod there, you know, in terms of the perspective being able to handle it. What we do now is we're adding just more of that instrumentation, like I'm saying, to make sure that you can bring these all flash arrays into a shared sand and not affect anything else as well as get the performance you expect. It could be one hell of a noisy neighbor, right? Yeah, right, right. So, that's where we add that deep instrumentation, right? And then on the VDX fabric side, one of the key things we're doing a couple of things, is beyond that deep storage-related instrumentation, we have very low latency as well, in hundreds of nanoseconds type of capability. And then also, we have the ability to go in and take buffers that are associated with a number of ports, pull them together and get a little bit more of a kind of performance optimized for a large packet kind of storage workloads, right? That plays well also within the flash environment.   Absolutely. Can you talk on the Ethernet side? You know, what are you guys seeing? What are you driving? I mean, things like Rocky and IWARP are coming up in a lot of conversations, you know, so often it's Ethernet's doing there. What's your case positioning? Yeah, so from a pure switching latency perspective, like I said, we're in very good shape, right? We're hundreds of nanoseconds type of storage heap, and Infinity Band's always been kind of in that area of ultra-low latency, and then it's got the benefits of the RDMA capability and stuff. I used to work in our Infinity Band a long time ago, right? When it was going to take over the whole kind of, you know, PCI world, parallel PCI, right? So, um... 3GIO, right? Yeah, yeah, exactly, exactly. And then HyperTransport came out and everybody freaked out. So, um, you know, I think what we're going to see with IWARP and Rocky is really take a run in Infinity Band in terms of kind of where it's been able to go and be that kind of back-end cluster kind of interconnect. And so that's really where we see that making probably the most inroads overall, because it's combining not just the latency, but all the off-load type of capabilities as well. So we spoke to a customer from Australia, and he told a great story about having dual data sensors. Yeah. Using your technology, Ethernet and, you know, EMC technologies to have two hot data sensors, and he can just shut one down, and the workloads are always moving between them. He doesn't have to do DR anymore. Is there anything specific in your switches that enable that? I guess that's the first question. The second one is, do you see that happening a lot? I think he said he was the first customer in Australia to do it. I mean, it just sounds so appealing to me, right? Take that headache of DR away, you know? Yeah. And he says that you're a key part of that. Yeah, so we have a couple capabilities in that front, and what we announced last week was, so we build a data replication fabric that's really good for heavy-duty storage, and we do a number of things that optimize those connections between the data centers for large-scale storage. We optimize the TCP windows over storage. We add multi-pathing, excuse me, failover and load balancing into the WAN links, which are notoriously unreliable. Right, okay. And then we even add some kind of WAN testing optimization so you can test your apps when you lose some WAN links and kind of see how they perform, right? That's interesting. And so the interesting thing is, and we're doing that both for Fiber and IP. That's why I'm very clear to say, you know, I'm the storage networking person, right? I don't fiber-tail networking guy. And so that kind of capability gives those customers that ability to go handle it, and the important part is you handle it at scale. Because if you're doing it at large scale, that's when that stuff really starts to matter. You don't want it to be fragile, right? I'm sorry? You don't want it to be fragile. You want it to be reliable. You want it to do it, as you say, at scale. We deal with mission-critical, business-critical type of environments, right? That's where we, you know, that's our forte. All right, so, Jack, to close the interview, you know, here at EMC World, talk a little bit about how EMC's been getting involved in the IP storage networking piece with Brocade. Absolutely.  It's even scale IO, right? And it's solution, you know, for software-defined storage. And really, what EMC did is they looked at our technology offerings, our VDX, Ethernet Fabrics, and said, this solution will couple to their storage, really, kind of like how Fiber Channel makes that total solution better. And basically, what they did is, and you'll see on the show floor, a number of solutions where they've taken our technology branded it themselves, positioned as IP storage networking, right? IPSN, I like to call it. And are showcasing it as part of these solutions, right? Sometimes it's hidden in as part of, let's say, VSpec's blue type of architecture. And then sometimes it's right there, sitting right next to the VNXC. So, we're very excited about this show in terms of what it means for the partnership as well as for Brocade. Alright, well, Jack, we're going to have to leave it there. You have a huge partnership with EMC and Brocade, of course. Diamond Sponsor also, Brocade's one of the lead sponsors for the EMC on the Charity Water, which is happening right over here in the hang space so thanks so much for joining us. We'll be right back with lots more coverage here from EMC World 2015, right after this quick break.


Tommy here for Morning Systems and I have a new ZFS shirt. So I want to talk about ZFS. Seems like the appropriate shirt to wear for this topic. Now, I did a video called ZFS as a cow, but obviously there's more to the story. The copy and write semantics are really important to understand. But what's the next question might be, what about those specialized V devs such as log or cash? And don't those also play a big role in how that data gets to or egresses from that particular pool? And you are correct. But there's a little bit more to the story. It's actually a very complicated topic, one that, well, you'll find lots of discussion on many different forums about this topic. So I wanted to put some numbers together, show you how this works, and not just talk from an academic standpoint, which I'm going to have everything time index because there's going to have to be a little bit of talking going on to explain how these things work and try to be as concise as possible. But then we'll get to the demo part where we demonstrate how you functionally add these or remove them on the fly inside of TrueNAS. And what happens when you do this when you have a VM and you're doing some reads and writes back and forth to it and showing some of the numbers and how things adjust on there. Ultimately, it's functional to teach you how it can be done inside of TrueNAS and, you know, academics so we can understand what's going on behind the scenes. And I also will leave links to all the articles that I talk about in a forum post that I have or just dives into a lot of different topics of ZFS. I am a big ZFS fan, obviously, for those of you that don't get the joke on the shirt. I have been called a ZFS cult member because I'm preaching about the wonderfulness of ZFS and it is a wonderful file system. So that's kind of the joke about the search. Yes, there's a link to those in case you're curious or care. If not, you can skip right over that. Nonetheless, before we get into the details of this video, if you'd like to learn more about me and my company, however, LawrenceSystems.com, if you'd like to hire us for a project such as storage consulting, there's a hires button right at the top. If you'd like to support this channel, otherwise, there's affiliate links down below to get your deals and discounts on products and services we talk about on this channel. Let's start by talking about how write caching works in ZFS. There are two types of writes, asynchronous and synchronous. An asynchronous write provides immediate confirmation when it receives a write request even though the write is still pending and has not yet been committed to disk. This frees up the application waiting for the confirmation and can provide a performance boost for applications with non-critical writes. That's because it's lying to the application. Essentially, it said the write happened even though it didn't. Now, a synchronous write guarantees integrity by not providing confirmation of the write until the data has actually been written to the disk. This type of write is used by consistency critical applications and protocols such as database, virtual machines, and NFS. We'll do a VM and NFS demos later in this video. All pending writes are stored in the ZFS write cache. This is located in RAM, which is volatile, meaning its contents are lost when the system reboots or loses power. To maintain data integrity for synchronous writes, each pool has its own ZFS intent log or ZIL residing on a small area of the storage disk. Pending synchronous writes are stored in RAM and also logged in the ZIL simultaneously, only for synchronous writes. ZFS is a transactional file system. It writes to storage using transactional groups, which are created in a set every five seconds. These groups are atomic, meaning the entire contents of a transaction group must be committed to disk before it is considered a complete write. That is the copy and write mechanism that I discussed in my video where I said ZFS is a cow, linked down below. So what happens if a failure such as a power loss or kernel panic occurs? Everything in RAM, including all pending transactions and asynchronous writes requests are gone. If there was an interruption in the transaction group performing a write, that transaction group is incomplete and the data on disk is now out of date by five seconds, which can be a pretty big deal on a busy server. But keep in mind that pending synchronous writes are still in the ZIL. On a system that's on startup, the ZFS will read the ZIL and replay any of those pending transactions in order to commit those writes to disk. It's actually a pretty solid system here. Pending synchronous writes still get written without any losses, no more than five seconds though of asynchronous writes would have been lost. Five seconds as I said is a big deal, but just so we're clear on it's only asynchronous sites lost because it replaced those transactions. But this comes at the cost of performance. So let's talk about performance and where that ZIL data is stored. For applications using synchronous writes while having ZIL reside on the storage just can result in poor performance because the ZIL writes and reads must compete with all the other disk activity. This can especially be a problem on a system with a lot of small random writes. The solution to this issue if your workload requires synchronous writes is to move that ZIL to a dedicated log vdev. And there's a few things to keep in mind if you want to do this. The log device requires at least one dedicated physical device that is only used for the ZIL. You should mirror these devices because safety and redundancy in case one of them were to fail. The devices should be really fast, but they do not have to be very big. The ZIL only needs to have enough capacity to contain the synchronous writes that have not been flushed from the RAM to the disk. This process occurs every five seconds. So how much data is that? And let's use a 10 gigabit connection to your TrueNAS server as an example. With a max 10 gigabit connection, the maximum possible throughput ignoring overheads and assuming one direction in a perfect situation would be 1.25 gigabytes per second. And because that flush happens every five seconds, the most you would see written to your log device is five times 1.25, totaling 6.25 gigs. That's it. You're hearing that correct. Only 6.25 gig max would be the absolute most you would write to that log device. So if you bought a one terabyte one, you're probably not going to use all of that log device. This is, as I said, why so many of them are so much smaller. Now let's talk about ZFS read cache, of which there are two. The first one is ARC, which stands for adaptive replacement cache. And it is a complex caching algorithm that tracks both blocks and cache blocks recently evicted from cache to figure out what to cache. ARC is all in RAM, which leads people to thinking ZFS is memory hungry, but it's not. ZFS just does not let any unused memory go to waste. It also should be noted that ARC is a native part of how ZFS works. And the more memory it has to work with, the better it performs at caching. Now the L2 ARC or cache VDEV is a storage device you attach to your pool that is a much simpler system compared to the ARC, allowing for efficient write operations at the expense of hit ratios. Just kind of a simple caching system. Of note, L2 ARC will rarely have a cache hit ratio as high as the ARC. This is as expected, but not a bug. L2 ARC is just a simpler, cheaper way of caching more data than the ARC can fit. The most demanded blocks are always going to be available in ARC, and the L2 ARC is just a catch-all for some of the marginal blocks, hence the lower hit ratios that are on there. Now the real question comes. So when should you use an L2 ARC for read cache? For most users, the answer to this question is simple. You shouldn't. That's it. The L2 ARC needs system RAM to index it, which means that the L2 ARC comes slightly at the expense of memory for ARC, since ARC is an order of magnitude or so faster than the L2 ARC and uses a much better cache regular them. You need a rather large repetitive set of data to be requested that exceeds the ARC for the L2 ARC to become worth having. So if your goal is to have a fast cache for frequently accessed blocks, buy more memory for that system. It's the best investment you have. This is why high performance CFS systems always have so much memory in them. It is also worth noting that if you have a right intensive workload or don't frequently request the same data, it's also not very useful. So the goal is always to have as much memory as possible. That's where you're going to get the best read performance on there. It's really that simple. There's not anything more complicated than that. But if you do have a workload that exceeds your RAM or you have maxed out the capacity of your RAM, then maybe it's time to consider an ARC device. Now of note, you do not have to put these in in pairs in the system because they're only caching data that already exists on these storage VDevs. Therefore, if they were lost, if a failure would occur, it's inconvenient, but not catastrophic because if that data is not there, it just pulls it back from the drives like normal. Now for the fun part, playing with this demo lab that we have set up running TrueNAS 12.0 U8. Essentially, this works the same in TrueNAS Core as it does in scale. Our demo system here happens to be a core system. Now we have 15.9 gigs of RAM, but this is really not an overall performance system. I want to bring it up because we're not going to be running a whole lot of benchmarks. We're just going to be talking about functional things and how to get them done in here. ZFS cache, because I have a VM running on this attached over NFS, ZFS has decided to cache things with the ARC as we talked about. It's not that it's RAM hungry, it'll use as much RAM as well is available in this system. 15.9 or 16 gigs of RAM being available means the cache is currently able to use 11.7. And yes, in case you're wondering, based on services running on this, you will end up dynamically, if I add more services or install something like a jail on here, it just automatically resizes and scales it. It's only using what it perceives as free memory, not used by other services running. So that's dynamic and nothing you really have to worry about in case you're wondering. Now the system itself is set up with NFS attached to XCPNG. I have a demo system right here. And I have it up live and running and it's attached, as I said, with NFS and we have sync disabled. So let me cover that setting real quick here. We're going to go to storage, we're going to go to pools, click on little buttons there, we're going to edit the options and we can see sync is disabled. And we're going to run a simple test where SSH into these. The top one is the Ubuntu one and down below and probably I should show the command because people will wonder we're just running Z pool IO stat dash V the name of the pool, which is the lab pool and one means refresh every one second gives us a really simple it is actually just keeps rereading and telling us what the stats are. We're going to actually make it a little bigger so you can kind of watch this populate. And we're going to run just some FiO, but specifically I have this set up to run FiO with a write test, we're just going to write about a gig of data here and see what happens. So here we see it writing. And you can see down here the data as it's refreshing. All right, we're writing quite a bit of data here to the drive 1.4. You can see by the way these are also just RAID Z1 and we have three SATA SSDs in here, not a particularly fast system, but good enough. So utilization Q merchant out we're writing at about 93.1 megs a second. So right, there's our rights. And if we go back over to the system here and switch over to here and we're going to look at how it perceives this. There's our disk rights that we just did. And we can see the throughput as it goes through there. So not bad, not great, but not bad either for what it's writing. Now on the fly, you can change this, we're going to sync always. But by the way, we do not have currently installed a slog device, but let's go ahead and run that same test again after we do this. So we're going from 93.1 megs, we're just going to rerun the same command. And let's see how fast we can write to it with a sync always turned on. Looks like we're writing at about 13 megs instead of 70 megs. This is that forced commit. Now, when you have the sync disabled is essentially lying to the XTP and G system, it says, oh, no, we have that right absolutely committed. So because we're saying no, don't tell XTP and G or whatever's writing to this particular NFS mount, until we actually sync it, don't give the system call to send more data because we're not ready. We're not syncing yet. This just results in this just results in extremely low performance. And even with a lot of drives, this is where you run into the need for a ZIL or to turn the sync off. So currently with this 21 megs, 17 megs, it's going to take a little while for this to finish. And it's because it's writing so slow. Let's go back over to here in true NAS. And now we're going to talk about adding and we have in our just pull here. So if you look at the disc, there's those three sadas that we're using for the drives called the lab pool. And here is this MVME drive we put in, we have been up a small one laying around, and it's snapped into the system. So we're going back over to the pool. And by the way, we can do this while it's reading, writing, we don't have to shut anything down. We want to go here, we want to add a V dev, got to choose the type here of log, find our MVME drive, go here, and that's it. You're going to get a warning, a straight blog V dev may result in data loss if it fails combined with power. But as you tell you don't have just one. So we're going to have to say the word force. They really want you to know that if you do not commit these in pairs, there is that potential that you'll lose this and lose the RAM. If there's a catastrophic failure, you could have a problem. So they're reminding you of that that these should be set up in pairs. We're going to add the V dev and a disk or a race in the pools extend. Yeah, we're just letting know that this block device that we're adding is going to do that. Actually, let's check real quick. It did finish writing and you can see it's written rather slow, but let's see if it's finished. And we'll double check and show the screen because we're going to do this and hit add V devs, or jump over here. And just like that, look, we've added it. And now it shows up right here as the log device. So here it is. It's got 13 gigs, but back to what I said earlier, but it doesn't have to be that big, which is fine, makes this a little bit more ideal. Now there's small rights and transactions that the system is going to do with this VM. So there's going to be a little bit of data that you're going to see here popping it out, but let's go ahead and run that right test again and see if we can beat our 17 megs. So run FIO and let's see if these little rights make a difference. Hey, look, we got some data going over here. And we're not quite up to the performance and this comes down to the systems who are hitting in the 70s, but we're up to closer 60. So you can see the immediate effect of adding this definitely improved our rate performance, not to the word it was, but still reasonably good. So yes, absolutely. We were improved and it's now committed and flushed out some of that transactional data. So it sits with about 362 bags left, even though the file we're testing is one gig. As I said, it's not exactly a one to one ratio for the size of the file you create versus what ends up in the intention lock. And as it kind of expires out, commits those, and we're back to don't really have anything left. All right, go back over here and let's remove it and you can add these or you can remove them. We go to status from clicking on the pool, click on this, and we can just drop it. Confirm you want to drop this absolutely. And it's gone. Well, almost. All right, now it is got a little head of myself there. That's it. Now we've removed it. And if we go back over here, you can see it doesn't show up anymore. So switch back here. Go to pools. Same process again that added as a cash drive. Now, before we add it as a cash drive, let's go ahead and do this. We're going to them run FIO. I don't care about a right test anymore. So we're going to block out this. This is a random read test. FIO is just a really simple utility. So I'm using it's not in depth. And this is not accurate or benchmarking. This is to give you some general ideas of what happens. So if we run this again, and we look down here, you're going to see much heavier writes, and we'll see where we get with this. So it's doing the rights going to take a few seconds to complete. But we're doing this at about 63,000 IOPS, and we should get a speed test at the end. It should tell us about how fast this is with the random rights, or we can even go and look at this because this is what's going to be in there. I'm sorry, random reads, because we're doing this is a random read test. If we go over here, you'll actually see, which is kind of interesting, even though we're writing at these slower speeds, you can see it's able to get a substantially higher throw put. Now, the reason for this is really simple. And we'll go ahead and switch back and forth to it. I even put a larger file in here, but it's also part of the way the adaptive recache works. So if we go back in here, then run FIO, if you can read through where it's wrapping right here, we actually sizes to be a 10 gig file. But even though it's a bunch of random reads from a 10 gig file, if you notice at the beginning here, I had mentioned there is 16 gigs of RAM and 11.7 gigs of it is all for this cash. This is why you don't see a ton of reads and writes on the disc activity. You're seeing basically a massive amount of this reading going on in terms of pulling it right from the arc. This is ideal. This is not necessarily making it easy for me to benchmark it because it seems to be an unrealistic number. You're like, Tom, you're not measuring a dry speed. I'm like, well, do we have to? Don't we want to see the efficiency of things that are going on in a VM and isn't running a VM? Frequently asking for a lot of the same data. So the more memory you stuff in here, the better it is because that's where that, as they referred to as hot memory is going to say, yes, those are all the objects that I put in there. This is that hot demand data that you're saying that should be in here. So you keep requesting it. Let me keep giving it to you. Let's go over here to the reporting. And if we look at what's going on, we switch over to ZFS. This is how you end up with these arc hit ratios that are really, really good. So here we go. Hit versus miss 512,000 hits versus 5,000 misses. And this are, you know, quite good numbers and what you're hoping for. Now let's go ahead on the fly and maybe you're noticing like, Hey, what are these over here where it says L2? That's where I was doing a demo before I hit record. So let's go back over to the storage pools. And now that I have record on and I'm doing it in for this demo, we're going to add a cache feed of same process at it over here. And these, it does not need to be in pairs or redundant. The reason why is really simple. It's just data that's read from your existing storage pool pulled into the cache. So no problem. It's not a big deal if it's lost. It's just annoying. And it will just repopulate that as in each time the system, if it loses it, it can go, Oh, I know where that was. It was just pulled to put in there. So now we've added this. And now we see that the cache one is here. Now that we know that this random read test, let's see what happens now. Now currently, a little bit of memory is going in there. And it's just the frequent writes. And remember, this is a very basic, the L2 arc is a more basic cache. And it's going, All right, I'll put some of this data in here, just from the running VM. But if we run this, it's going to populate it a lot faster. So we're going to start seeing the rights kind of populate in, but we're probably not going to see a massive change at all in performance. As a matter of fact, the IOPS is roughly the same. If we scroll back in here, it's not substantially different here. And the reason why is because it's just pulling still from the cache. Now we have to fully exceed the cache for to start the arc cache in order for the L2 arc to start being effective. But there's still at least some data being swapped out and populated in here. And that data will just stay there is part of the data. And this can be beneficial, as I said, in certain workloads, such as if you may need a cache, if you have lots of large files that many people are requesting that large file, if it's larger than the arc can end up in likely to be hit on as a successful cache on the L2 arc. But overall, the reality is the performance differences are massive between memory ram and a block device storage. So if you can, if it's better for your budget, you can, well, better for your performance, not necessarily for your budget, as you put more memory in a system. And this will allow it to have a better caching. But the caching, it still works. The adaptive one still puts some data here, but it can take a little while before it exceeds the memory. So we have to exhaust arc in there. I don't really have a demo, I guess I could try one more test where we just make this file big. So let's go ahead and do this and see where it goes. If we said, we're going to write a file, not 10 gigs, but let's say 25 gigs, let's go ahead and run this again with a 25 gig test, which should, depending on if it's a different amount of data, it's supposed to be read random file it creates here, hopefully it will exceed the arc cache and actually start pulling a little bit more. And we'll see some read operations scroll this up a little bit, but you'll see some more read operations on this cache. Because as you can see from these tests right now, it's just not hitting the read operations on it. So this larger file did result in a different change. We have 169 seconds here. So a little bit slower than our, if we scroll up the 295 here, if we look at this under XEP and G, we can see this test that we did here, then here is the writing out of that large file. And back over to here at the end, it kind of peeked out again, probably when it was pulling it out of arc. So the first part was very random. And this is probably more realistic. But once we got to the part where it was repetitive and arc was going, Nope, I have this. And it was able to send all the data. We see it ramping back up because it was asking for repetitive data. Now, as I said in the beginning, I'll leave links to, well, many of the other topics I've talked about around ZFS and planning and storage pools and ZFS being a cow. And well, the whole list of articles I have over in my forums, because there's still a lot more to understand. But I hope this video gave you some understanding better than you had before about how some of this works. It is a complicated topic. It is one of the reasons it's misunderstood just due to the complexities of it and understanding performance of file systems is a little tricky.  And I just love the fact that we can do this on the fly, not rebooting or anything. Just go and, Hey, let's add parts of these block devices, remove them and understand a little bit better how they work. I really encourage playing with it in your own lab. This is how I gained a better understanding it. But before I started doing this commercially, it's one of those things of why I like spending time talking about it. Because well, I think we need more people in the industry that understand it. And it's just a fascinating topic. And I imagine a lot of you, if you've made it to the end of this video, it was a very interesting topic to you as well. As always, if you want to have a more in-depth discussion about this, hand over to my forums and see you in the next video. Thanks. And thank you for making it all the way to the end of this video. If you've enjoyed the content, please give us a thumbs up. If you would like to see more content from this channel, hit the subscribe button and the bell icon. If you'd like to hire a short project, head over to laurancesystems.com and click the hires button right at the top. To help this channel out in other ways, there's a join button here for YouTube and a Patreon page where your support is greatly appreciated. For deals, discounts and offers, check out our affiliate links in the description of all of our videos, including a link to our shirt store where we have a wide variety of shirts that we sell and designs come out well randomly. So check back frequently. And finally, our forums. Forums.LauranceSystems.com is where you can have a more in-depth discussion about this video and other tech topics covered on this channel. Thanks again for watching and look forward to hearing from you.


All right, welcome to day three of Android of code. I wonder what we're gonna do today. I changed the stream up a bit, moved the keyboard around. People were saying it was too disjoint when it was up above, so. Now it's closer, it's good. The new thing also, we're gonna have the chat be displayed on stream itself. Now I haven't tried it before, so. I don't even know if it works, but it's supposed to work, so. Might as well try, right? All right, let's look at today's task. Do, do, do, do, do, do, do, do, do, do, do. Boom, boom, boom. All right, task three, day three, to bug on trajectory. Okay, there's very minimal searing on the areas. Let's see, due to local geology, trees in the area only grow on the exact integer coordinates in the grid, cool. Okay, okay, so it repeats. Okay, yeah, all right, so this is the input and then it repeats to the right. Okay, yeah, so we have a map and then the map repeats. We start on the top left corner and we need to reach the bottom. Okay, so here we would just go here and here and here, okay. And the bottom is on your map. The toboggan can only follow specific slopes. Okay, that prefers irrational numbers. Start by counting all the trees you would encounter for the slope. Wait, okay, so start by counting all the trees you would encounter for the slope right three down one. From your starting position at the top left, check that the best unit that is right three. Okay, down one from there, you can move on the map. If the locations you check in the above, except marked with the O where there was an open square. Okay, so we go, so zero, one, two, three, and zero, one, two, three. Let's go down one and right three, okay. The axle was a tree. An example traversing the map using this slope would cost you to encounter seven trees starting at the top left corner by following the slope of right three and down one. How many trees would you encounter? Okay, this seems a lot more work than, oh, we got our first chat message happening. All right, so this seems a lot more complex on first glance than the other one. I mean, it's a lot more real world, but the other ones were like data manipulation things. But this time it's more like we have to look at coordinates and stuff, okay. Let's just try it out. We just take the demo input and we open a bit of code. And we already made a new directory, so let's go into day three. Make there, do we have a directory touch day three dot HS? Let's start day three. Let's start day three. Module, main, where? Main, here goes Webster, Ellen, hello. And let's create new file called test input. Here we paste the input and then we will read this input. Let's just try to not get input file. Let's pass to IO list of strings, right? Yet, input, this is just read file, right? Is that half of read file? Oh yeah, this is just unlines over read file. So we split it into strings, pretty easy. And then let's just say, yet, input, test input, type that to print. Let's just see if we managed to read it correctly. We say gtd3.hs, oh, day three. And then we will execute it. Okay, so we got the input. Now let's think about the problem. You can see it here, right? I'm a bit in the way, but that's okay. So we will follow a slope down and we're supposed to count all the trees you would encounter for the slope, right? Three down one. And then the pattern repeats itself. Okay, so in Haskell we have this function called repeat, wrong one, gti t repeat. We have even cycle, which if you say take five of the list, if we cycle the list one, two, three, and we take five of it, it just repeats itself again and again and again. So we will to encode this repetition because we're in a lazy language, we can actually just cycle. Instead of even, you know, we don't even have to like modular calculations, we can just literally cycle the lists. Less of that aim. So cycle, all cycle is just map cycle. We're going to cycle all of them. And then we start at the top. I'm just going to close this. This is another project I've been working on. Save the changes. Yeah. So we're going to go down, right? Down one, right? Three, one, down one, right? Three, down one, right? Three, down one, right? Three, down one, right? So, okay. What is the pattern? So I, let's say it's okay. So we have, let's look at it as coordinates, i, j, right? And I will be zero. I was first zero, then was three. That's how it's like. Yeah. So first it's okay. Okay. We don't even, we don't check the first one. Okay. So the first one is always, yeah. So we always start here and then we go zero, one, two, three. Yeah. Okay. So it's three and then it's three, four, four, four, five, six. Five, three, six, nine, so on. Okay. And then you always go down one. So, okay. And how long is the input? So we're essentially asking just take every third element of the list starting from three. Is that correct? Zero, one, two, three. Zero, one, two, three. Zero, five, six, seven, eight, nine. So we're taking the third. So it's first is plus three, then it's plus three. Yeah. So it's every third element, right? Yeah. So if you start, if you're taking the index from one, because this is like the fourth element, right? Yeah. And this is the fifth, five, six, seventh element. So we deduct one. Okay. So anyway, zero, three, six, nine. Now, what is the length here? Let's load this. Get the test input. And let's do print the length of it. So how many lines is it? And how long are the lines? Okay. So it's 11 and 11 is not a multiple of, it's not a multiple of nine, multiple of three, right? So this will be zero, three, six, nine. And then, you know, 10, 11. The next one should be 12, but it will be 12 mod 11. So there'll be one, four. So can I just generate list list? Okay. Let's just say take every third element. Okay. How do we do that? Take every third. So what we want every third to do is that we want every third. So we want to take every third of, you know, one of zero, 10 to be three, six, nine. Okay. So take every third. Okay. Of access equals. So okay. So we drop three access. Let's reload it. And let's say take every third of one, two, three, four, five. One, two, three, four, five. Let's just do one, two, eleven. I guess it's four first. Okay. So we want to, yeah. We started at one. Okay. So we want to drop three. Okay. So take every third. We'll operate on infinite lists. Right. Okay. Can I like do this code completion or something? Nice. Okay. So it will be a where. So we'll be dropped. So we drop to access equal drop to this will be drop X drop to access. So we guess let's say this will be why and this will be wise. And this is the first element after we drop two. And then we will keep taking every third. Let's reload. Three, six, nine. What if we take ten? Ten. Take every third. And now we just want all the integers. Three, six, nine, 12, 15, 18, 21. Okay. And then we're going to map. We are in English mode. We're going to map mod 11. This will be like this mod 11. Three, six, nine, one, four, seven, ten, two, five, eight. So these are precisely the indexes that we want. So chords. We don't actually need to cycle them. Let's just inefficient. So chords. That's going to be a little spin. Coords is going to be take every third. So, okay. So here we will say, so let's generalize this, right? So it's going to be take every n. We're going to int. And we will drop ten. Take every n. And then I like having a list here. Take every n. Because, you know, it's definitely going to be the case that for task two, part two of this problem, we're going to have to do something else and write three down one, right? So let's just prepare for that right now. Take every n two. So this will be n minus one. Take every third will be take every n. So we start with one, take every n. And then, yeah, so this is exactly what we want. Okay. And then, so now we have an infinite list of coordinates. And now we want to take the hookup input. So it takes a list of strings in the lines. It takes a list of coordinates. And it returns list of values at that point. Lockup in input. So if we don't have any more input, we don't care about the coordinates. And we will say empty list, look up in input X axis. So if we have a line and we want, so then we have the chord here. That is going to be a line. I'm going to call this a line and a line. It's because it's going to be lines of input. And we're going to do L and C. You know, actually, you know, so we're not, we haven't. So here we map the mod over. So we're going to do line, C, mod, module, the length of L and concatenate it to look up input. Okay, let's look it up. Let's see here. Okay, so let's do this. Do TI, test input. There's going to go test input. We're going to print. We're going to apply look up in input to the test input in the chords. We have result, run main. Okay, so first one was supposed to be, oh, okay. Yeah, we don't actually, we drop the first line as well. Could we start going down? So the chords here are always going to be zero. And then, all right, three, zero load, run main again. So first we don't hit, so first it's going to be zero. And then it says period. Let's print the chords. Zero, three, six, nine. Okay, so this one is going to be zero. Zero, zero, right? Let's print the, okay, yeah. So this is the input, right? Test input. So first one should be nothing. Second one should be, so I have one. That is this line, right? And so if we look up, so we look up here, we look up three. Okay, but are they, no, so this is zero, one, two, three, yeah? If we look up four, we would get the three, right? Yeah. Okay, and then, so okay, so that's this one. And then we go one, three, four, five, six. We hit this tree. So let's look up line two. So that's zero, one, two, three, four, five, six, right? That's a tree. Okay, but look up in input, run, give us something else, right? That gives us dot for the second one. Oh no, yeah, okay, yeah. The first one here is going to be the first one, right? This, and then it's going to be the circle. Yeah, so it's first going to be circle. And then x, yeah. So it's dot, dot, x, dot, x, x, dot, x, and then x, x, yeah, okay. All right, I think we got this one. So now we define an easy function is tree char to blue is tree equals. So this is a tree. Anything else is not a tree. So we look up in input. We filter is tree. And then we see how many that is seven. Good. Now let's get the real puzzle input. Okay. So here, new file, input. And let's see. Okay. And we have the test input. Let's see what happens. We will take it. Let's just go here. Get input. Input. Pipe it a count. Let's just write this as a function. Count print count trees test. And then we say print dot count trees. I think I should be able to, like, surely I don't have to press it with my mouse. Anyway, this should be, let's just change it to be the piped one. I don't know. Then I don't have to give names to things, you know, just, oops. Run it. Reload it. Run main. 178. Let's see if that's correct. We got the first one. All right. Part two. If for, so, yeah, okay. Terminal number, if for each of the following slows, you start at the top of the corner, traverse them up all the way to the bottom. Okay. Yeah, this is exactly what we anticipated, right? So, count trees. Let's change that, right? Count trees takes in an int and an int. Count trees gen. And this is going to be, right? And this is going to be down. Okay. So we still do the length filter history. So, cohorts, we need to generalize cohorts. Cohorts is going to be, cohorts is going to be gen, cohorts, gen. So that's where we need to actually put the right, the right and the down, right? Is that so? Here we say, cohorts, cohorts, see. Cohorts, see. Cohorts, gen, see. Okay. So it always starts with a zero. Well, this is going to be right and it's going to be down. So here we say, right? And so, so my question is right, two, right one down two, because you produce two trees. So right one down two. One, okay. Right one down two. Right one down two. Right one. Two. Right one on two. Okay, that goes down only one. So that goes down, right? Yeah, that goes right once. But then down two. So it doesn't go right one, right one. So we have to change that for that one. Okay, but we want, right one down two. So you want to take every other, you want to take every other element in this list. Take every and, take every and down. That's just job zero, right? That's possible. Yeah, so we can just drop take every and down. But we want it to, we want it to, we want to divide by, by the, we want to multiply. Wait, I'm thinking about a bit. So we're multiple. So we're taking every and down. So this will work for all the other ones, right? But let's see here. So cases equals, what are the cases here? So it's right one down one. This is going to be, and then it's going to be, oops, this is how you write it in Haskell. Then we're going to go three, one, five, one. Three, one, five, one, seven, one. And then one, two, cases equals, there's a list of int comma int. And the input will always say the same, but the countries will change. So we will change this into like this. Because then we can just map over the cases. Okay. So let's try it out. Get input, test input. Okay. So yeah, I mean, this is not the best spot. It's okay. Okay. And then then we will just say print, map, count trees. Okay. So we can just do it directly. Print dot map, count trees, gen. Okay. So, okay, let's just, let's just not do it this fancy. Let's just say, yeah, I get input, test input. And then we will print, map, count trees, gen. You see, because otherwise like the, we will have to flip and flip and flip and flip, which is going to be too much flipping. So we map it over the input over the cases. Let's see here. So 27342. So it just works for the second one. Okay. I think it's, I think it's okay because it's one. We don't, I think we, we'd have to like divide by right. Let's just go here, print product, 336. Let's just run it on the real input and just see if it works. I think it should. I think we would have to actually generalize this one properly. This take every end thing. I think you would have to generalize it properly. But because the only case where it's not one right is going to be one. It kind of all works out anyway. So I think let's just, yeah. So let's just try it out, you know, see, see if it works. And if it does, you know, we don't have to do anything else. This is a nice thing about having an Oracle like we have here. You know, we can just actually check if we got it right. I mean, and we got it right according to the tests here. Let's see. That's not the answer, right? Yeah, I think this is because we didn't generalize properly. Let's go back. First time we're not getting it right on the first try. So, but this is also like if you have an Oracle, you can just use it right away.  So it's okay. I mean, I'm pretty sure the 1357 is correct because that's always just going down, going down, going down. But then for down two, should we just, I'm wondering if we could just special case that one. So what is that going to be? Oh, wait, I think maybe it's because we are taking every other coordinate but we should really be taking every other input. And then this should be right. And then we don't actually, I think maybe that was the issue. Yeah, I think that's the issue. We were like taking every other coordinate but we should be taking every other input. So we got 178, 7178. We're taking every n down, 3, 1, non-exhaustive pattern YYS in line 18. I think, so how does it work? Let's see. Take every n, 2, 1, 2, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. Yeah, so we take line, right, because we always want to take 0's line and then line 2. So these are the lines of the inputs. So we always want to take the first one and then we take every other after that. But we get an exception. So you know, so this will be essentially same as doing this, right? 0, 2, 2, 7, 6, yeah, 0, 2, 4, 6, 6, exactly what it would want, right? But this is wrong because this will be an empty list sometimes. So let's just do it here. k's off n-1-x's off. So if it is, we're not at the end, that's okay. This is why we defined this for, we were thinking about cycling, right? And we defined it for infinite structures. But then we're applying it to the input, which doesn't actually, which isn't infinite, right? So this is why we have to deal with it. So if we're applying it to an empty list, okay, so here we want this. But if we have the empty list, so I mean, so this will just be if it's anything else. Reload, now take every end here. 0, 2, 4, 6, 8, 10. Okay, let's see in the input here. So 0, okay, start here. Let me go right one down 2. This is line 2, right one down 2. Just line 0, 1, 2. Okay, we can actually look at the test input. Okay, so we have line, this will be line 0. So it's going to be minus 1 here. So 0, right one down 2, line 2. Right one down 2, line 4. Right one down 2, line 6. Right one down 2, line 7. Line 8, right one down 2, line 10. Okay, this is a different answer, but we still get the other one correct. I think this is the right one. So we should be taking every other coordinate, right? That was, that wasn't right. We should have been taking every other line, which we are now doing, right? Let's see, see if this is the answer. All right. That was the right answer. So we are one goal, start closer to saving our vacation. And we got to do some debugging this time, instead of just getting it right, which is hopefully more fun for you guys. It's not so much fun just to see me write the code. We want to explore why we were wrong on it. And why were we wrong here? Well, we tried to take every other chord, so we were like, okay. We should take every other something, right? But, you know, we thought, okay, let's take every other coordinate, which, luckily for us, actually works for the test data. But it didn't work for the input. So I think, and I think this is correct, right? So we want to, we want to take every other line and then, yeah. All right, so people don't like the music. All right, now it's at minus 42, 44.4 decibels. But, yeah. I tried, I tried applying compression to the audio. And it's like, it's a, it's a poster. I just, I just don't talk a lot enough when I'm, that's the problem really here. I, yeah, I mean, it is duct, right? I'm literally transmitting the music because it's Christmas music. You're not hearing it through the microphone. You're hearing it from Spotify itself. Like I'm streaming what I'm hearing, right? It's an additive code stream. You're gonna, you need Christmas music, right? And this is cozy Christmas music. Anyway, I hope it's better now. I tried, so I am capturing the input and it's being duct also by the input capture, but yeah. Anyway, thanks for looking in today. I'll be back tomorrow, six o'clock sharp for episode four. And we can see that it's getting progressively harder and harder, right? So, you know, who knows? Maybe tomorrow I won't even be able to do it. I think I should set a maximum. You know, if I'm spending three hours on it and not making any progress, then that's a bit too much. But you know, it's part of the fun, right? Figuring out how to do it. And that's also like, I don't know, that's how we solve things usually. I try my best. And then if that doesn't work, usually better to just go do it. Go do something else for a short while, take a break, you know, go for a walk, then come back and do it again. So, worked for me so far. Anyway, thanks for dropping in and see you all tomorrow, six o'clock. And if you're watching this on YouTube, you missed it live, but you know, there's a link in the description where you can check out the stream. Alright, see you all.


Welcome to Monday and also Welcome to the software heritage talk by Nicola Dandrimon. Thank you So hi, I'm Nicola Dandrimon and I will talk to you about the software it is project I'm really really glad to be here and to be able to talk to you about software it is It's been a long year of work And you'll see that it's just the beginning so The soft software is very pervasive It's at the heart of our society. We use it everywhere. We have software in our pockets. We have software everywhere around us. We have software in our bodies and It's really at the heart of technology Appliances in a house Contained 10 million source lines of codes Phones contained 20 million lines of code cars can contain up to a hundred million lines of codes And it's not gonna stop anytime soon. I mean we're starting to put software in every single thing that Going to market right now Software is the mediator to access all of our knowledge Information is one of the main pillars of modern societies done with software and software is critical to reproduce research Software must be therefore collected referenced and made accessible because it embodies our Knowledge and our cultural heritage Software is really fragile Have you tested your bike ups recently?  Did you have an account on Gittarius or on Google code? Both of those have shut down Software is scattered all around, you know, we have several forges github githlap beat bucket source for alia of your personal home page CDs in drawers Software is really everywhere and there is no single standard to retrieve software. There is no uniformity. There is no stability urs change Often even in Debian we change the URLs to our repository quite often Software migrates it moves from one host to another because host us close host us change policies so With the software habitat project What we are trying to do is to collect organize preserved and share all the software source code machines to execute so Software is executable and human readable knowledge, which is an all-time new even hardware software with FPGAs with ASICs and text files Can be interpreted forever Of course software evolves over time The development history is really important to understand software And software is really complex It has a large web of dependencies. We get millions of lines of code So software is not just another sequence of bits We need to be able in a software archive to make sure that we can interpret the software Its history its dependencies everything that we need to understand This tiny C file that exists on your hard disk So software it is working on the foundations We're building infrastructure base infrastructure to allow for all the applications that You could use a software archive for Cultural heritage industry research education We're laying the foundations So that people can build applications on top of our archive We're preserving the world software heritage by building a structure archive of all the world software So we can preserve the knowledge That has been put in science and technology over the last years We try to enable continued access to all digital documents and information and We're creating a building block for thematic portals and collections of software. We try to build Something that can be used to create better software for the industry the idea is that a Lot of companies have been running software for dozens of years and have completely lost the source of their software This is unacceptable because when you have a bug and You cannot fix it Life can be at stake So we need to ensure the long-term preservation of critical software We intend to ease the vulnerability tracking to get more secure software and We will make sure that software is traceable so that we can better integrate software and so that we can make sure that For instance when someone reuses a piece of code They're I mean they're using it correctly license-wise for instance for GP compliance Of course, we're also trying to support more accessible and reproducible science The global library referencing old software used in research fields So we are completing the infrastructure for open access in science You get open data you get open access for papers and you need to be able to have Open source code to be able to reproduce the results and We enable large-scale verifiable software studies with a comprehensive archive of Billions of source fights, so that's a lot of talk, but really what do we do? So meet the team We are seven people who have been working for different amounts of time Roberto and Stefano have been working on the project for the most part of two years now Antoine and myself have been recruited as engineers during 2015 This summer we've had two interns working on front-end and back-end and Guillaume has been advising us on industry issues our stack is Hardware hosted by Inria who is a big sponsor and initiated the project It's currently just one big hypervisor with a dozen virtual machines high-density storage array with 300 terabytes usable and To be safe, we have another copy in another server room. So we have the duplication of this hardware and We're working very hard to enable a mirror network to make sure that our contents can be kept as long as possible Our software runs Debian Every machine runs Debian. We use PostgreSQL for metadata storage. We use Python 3 and PsychoPG2 for the back-end Flask for web apps and RabbitMPU for task scheduling. So we're using only free software and we're building free software Our values are those of Debian. We use a hundred percent free and open source software licenses GPLv3 for the back-end code AGPLv3 for the front-end so it stays free forever Apache 2 for the puppet manifest because that's what the community of puppet developers uses We really encourage bug reports and code contributions for everyone interested in Pursuing our software preservation mission And to do that today, we are opening our forge so as a thank you to Debian and I mean with time the opening today So thanks to the Debian community for what is has brought to us so We have this infrastructure. What do we have inside it? so it's really exciting to work on Such huge amounts of files of commits of projects. We've got Replicated all the known for GitHub repositories. That's 22 million repositories Those 22 million repositories contain 600 million commits and 2.6 billion unique source files We're also importing all the Debian packages from snapshot.debian.org and we have imported the new projects FTP archive But we didn't stop there We also have been talking to Google and we have been fetching all of Google code before it closed So we have the 12 million 12 million Google code repositories Ready to be imported We also have talked to the archive team about Getorius and we have a copy of the two million repositories that were on Getorius We're storing all our files all our git repositories as Lose files so each and every single version of each and every source file is stored as one flat file in In a file system and on top of this file archive We have built a Postgres database for all the metadata. So the metadata is basically one big Directed icicle graph inspired by the git model Where at the bottom layer we have contents which are blobs which are files Those contents are stored in directories Those directories so software So to a source code is organized in revisions. So you do iterative changes So those revisions are stored in our database or releases of the software are stored in the database Then on top of that we have origins which are the source repositories that we're getting data from and Occurrences which are at every point of time where we looked at a repository the branches that were available pointing to Every single one object at the bottom so This is probably the biggest Distributed VCS graph in existence Yes, so 120 terabytes of files on disk 3.1 terabyte Postgres database for the metadata 2.7 billion files 2.2 billion directories 600 million revisions 12 million people 5 million releases The biggest dvcs tree in existence What will we do? We have a lot of planned features So right now our website allows you to look for contents by hash So the idea is that if you have a file a source file You can put it in the box on our website and make sure that Software heritage has archived it What we want to provide is provenance information for all the content so that we can say we have seen this file at that date on github.com We want to enable people to browse the contents because Putting all the software source code in a box is not what we want to do. We want to enable everyone to Look at the source code So basically we are trying to build a way back machine for software source code We want to enable full-text search in all of our archive that's That would be quite a price 2.7 billion source code fight that you can search into instantly and of course What we want to do is to enable people to download Every single bit of software that software heritage has archived And basically what we want to what we could provide is a git clone For every data source that exists whether it is a git repository and asian repository the Debian source package We will enable you to git clone from software heritage Of course There's also many more applications one could imagine All of the world software at your fingertips in a single graph We also have a lot of technical changes because software changes all the time so we have to handle the backlog and All the data that we have saved as a one-shot import which is the GNU.org mirror and the snapshot Debian archive We need to make sure that we can keep up with your dates We also need to make sure that we get the new repositories and commits on github we need Basically reliable standardized even feeds that we can tap into and that people can send us or cap can provide us for us to be able to Update and make sure we stay up to date And of course All the software is not on github all the software is not in Debian or the software is not in the GNU project So we need to expand we need to discover and classify all the software sources Which means that if you have a forge at your company and you do open source We can get your software If your Linux distribution and you have a forge we need to get your software If you know of someone's web page where software is released we need to get it. We need to get everything and And of course not everything is in gith or in the table or in the Debian package So we need to make sure that we have importers for all the version all the version control systems With we have started work on an SVN importer We need mercurial importers, DAX, whatever. It's a wonderful playground if you have time to help So how do you help? our forge is open on forge.software.health.org You can subscribe to our mailing list as SWH-Devil at inria.fr The link to the subscription page is on the slide and you can take a look at our wiki Where we store the public information about the project if Your company or your organization can join us as sponsors We are welcoming support from everybody in inria has initiated the project inria enables me to be here today Inria is the French Institute for research in computer science Inria contributed to the birth of the W3C 4500 people work there many prestigious scientists and recently inria has worked on TLS vulnerabilities And lots of stuff that have been made public recently Inria is fully supporting the bootstrap phase of software heritage But we do need the help of everybody so If you think your company can help us more info is available on our website Software heritage. It's a revolutionary reference archive of all the software ever written It's a unique complement for development platforms like github and We're building an international open non-profit mutualized infrastructure and we're ready to work with you If you have any questions feel free to ask right now Or you can contact us by email and you can look at our websites Thank you very much for your attention So the software that you're used you're using in this has been written Do you think that could be used also for snapshot WN org as the front end? so Currently we're using snapshot debian org as a data source so Just the designs you were talking about sounded very similar to what we already have which is Not very Worked on very much at the moment. Well, maybe it would be better for us to be using So I think the main code base, right so the main difference between what's been done with With snapshot debian org and what we're doing in software heritage is that we're unpacking all the source files Which snapshot that debian org doesn't do a Snapshot just has a pool of files that existed on mirrors. That's Do you also keep the? the Tables So, yes, we are storing the Tables to be so We have yes right now. We're keeping the Tables We're not sure that we're going to do that long term because Tar changes and As we know with pristine tar for instance So we want to make sure that the software is available now is available in 10 years in 50 years in a hundred years so the only really The only thing that allows us to do that is to store the plain source files Yes also a big difference with Snapshot debian org is that snapshot debian org stores binaries We do store binaries because people put everything and anything else in their git repositories But we are not really interested in that We have a file size limit, which is currently set at 100 megabytes and We are not importing anything bigger than that because it's very very probably not source code So we don't currently have the infrastructure to store big files Related question Suggestion the debian derivative sensors is downloading source packages from a whole bunch of derivatives Maybe you'd like to also store those files very much talk later about that Yeah, it doesn't pretty much that you did your own storage writing to this directly. Yes Have you ever investigated using cloud technologies like swift cluster FS sheepdog What not? Yes, and roof and roof FS. It's nice to so we've started with a Very limited budget. So we had to do what was the most dense storage for our price price tag basically So we went for the very simple solution We've optimized for data in gestion. So we have been able to import 2.7 billion files in a year But of course we need to make sure that we can retrieve those files, which is currently not very Efficient with our storage. So yes, we have we are starting to investigate over of a storage Storage capabilities the main issue we have with file storage is that so we have 2.7 billion files The median file size is three kilobytes. So the files are very very tiny They are source code files so For instance the git storage model breaks down very bad with so many files and Well, I mean Yes, we need people that know storage and that can help us Improve on that so the other question is did you investigate archiving language specific repositories like I don't know a sepa and pi pi may burn these kind of things. So Currently we have focused on github because Basically it was a low-hanging fruit. It's very easy to clone a git repository And it's very easy to unpack and to make sense of the metadata that there is in the git repository of course, we want to archive everything and Getting language specific forges is a very important step towards that So we're welcoming any help in doing that. Yes Yeah, very interesting project Software written by scientists is open source and not all data they publish Produces open data. So do you have training material training courses for scientists and for students to convince them? so Roberto de Cosmo who is leading the software a tech project has done a lot of outreach in the open access community and in the research community in general to Underline the importance of writing open of writing free software to enable reproducible research So, yes, I think we do have some training materials that Must be available somewhere. I think you should send an email to info at software tech dot org And I'm sure Roberto can point you to some material Hey, hey So this is a Very ridiculous question, but I think this is such an important project for humanity planning for the apocalypse Like for instance by planning to have an occasional snapshot put in Secure of facilities you can find possibly with the computer that could be used to access it So we haven't done any plans for the apocalypse yet but our interns or Intern working on backend storage is starting is enabling us to have a leader follower model for For our storage We need to put something in place to be able to replicate the database replicating the database has lots of issues because we have Something like four point five million people so four point five million email addresses that are easy to pick Just take a big list and you can spam everybody So there are some considerations there Making snapshots is of course a possibility It's gonna need a lot of storage, but it's certainly doable. Yes For now, we haven't thought about it yet Another security related question. There is an interesting article about the forgery the Gospel of Mary or something like that and Since you know an archive You might become the target of people trying to rewrite history or even Remove the documents or something like that and some cases that might mean just deleting it entirely Yes to obfuscate the fact that it's been done. Do you have any mechanism to worry about that or? so every single Identifier for objects in our database is intrinsic Which means that it's a hash of the content of the object. So for instance files are identified by their hashes Directories we write a manifest saying this directory contains the file with such ID and Etc and we hash that and that is the Identifier of the directory etc etc for all the layers of software heritage To be resilient to attacks What we need to do is have mirrors everywhere The idea is that if you copy information you cannot remove it anymore because it's everywhere. It's pervasive So this is this is really what we want to focus on now Is making sure that we have copies everywhere in the world in every jurisdiction in the world So we can make sure that if a government wants to take us down if someone wants to rewrite history then the history is available everywhere and They just cannot physically do that anymore Mention Software registry is there is there any relation to So the software registry you was talking about No, I Wasn't at her talk. So I Not sure I can Not sure I know what the software is but We can talk about it Is that everybody so far anymore? Does anyone see if there's any question from my RC maybe okay? Thank you everyone


Namaskar, I'm Professor Devdeep Purkayastha from IIT Bombay and I welcome you to my course, Business Fundamental for Entrepreneurs Part 2, External Operations. This is a module by Professor Sankal Pratap who will talk to you about the magic of great teams, winning teams. As background, Professor Sankal received his PhD and MBA from IIM Kolkata and he did his BTEC for Marine Engineering and Research Institute Kolkata as well. He worked across several organizations including the Merchant Navy and the Tata Group for almost a decade. After his corporate and naval career, he moved to academia and was a faculty member at IIM Tiruchira Palli and IIT Jodhpur for over seven years. Currently, he's a full-time professor at IIT Bombay DS School of Entrepreneurship. So, over to Professor Sankal. Welcome aspiring and existing entrepreneurs. I am Professor Sankal Pratap from IIT Bombay and the topic for today is the magic of winning teams. But which team are we talking about? For an entrepreneur, the idea of a team is not static. It keeps changing across the entrepreneurial journey. To begin with, an entrepreneur finds a few other aspiring entrepreneurs and finds what is called the co-founding team. And that team continues to work very hard day and night over a long period of time. Typically six months to one and a half year before it gets any traction from the market in terms of an angel investor or certain other friends who are ready to support them or certain family members who are ready to support them. And that is when they expand and hire their first 10 to 30 team members. And that is the initial team that works towards certain experiments with the market to create products or services which can be adopted by the market. Once they reach what is called the product market fit, that is when they get further funds from organized institutional investors and are able to hire much larger number of skilled workforce to expand and scale up. In today's session, we are going to cover the first two concepts of team for an entrepreneur. That is the founding team and the initial team. This is so because it is in the initial two to three years that the game, that the entrepreneurial game for a set of entrepreneurs is either won or lost. Once they start getting funding from large institutional investors, they change from being an entrepreneur to a business leader and the entire context and the game changes from being an entrepreneurial journey to a journey of large corporations. We are not covering the large corporation journey here. The content for the session is, as I said, the founding team formation and the initial team formation. And for both of them, we will cover various aspects. For example, why is it formed? What are the contents of the founding team? Where is it formed and when is it formed and so on. Every entrepreneurial journey begins with a problem. A problem to be solved for a certain customer segment, for a certain section of the society and hopefully a problem which is important enough for the society to get it solved and adopt the solution which the entrepreneurs are creating. Now this is going to be a tough and long journey because no entrepreneur, no matter how intelligent, how sharp and how committed they are know the entire nuance of the problem. They have to keep experimenting and keep releasing their versions of solution before they are sure that the market will adopt the final version. It's going to be a tough and long journey. A journey which will require them to spend a lot of their mental and physical energies. And this ability to keep spending mental and physical energy with very little gains and rewards for a long period of time, as you can imagine, is not easy. It can only be made possible if the co-founders have a certain pride in the problem that they are trying to solve. For example, let's say that I pick up a problem simply because it is what is called a hot problem. For example, something related to crypto or something related to AI, because just about everybody is talking about it, whether it be on LinkedIn, whether it be in certain parties that I go to, everybody is talking about crypto and AI and blockchain. And I pick up something there because it is hot, because everybody wants to talk about it. But if I am not committed to this problem, if I do not have a certain identity, a certain pride in solving this problem, then as my mental and physical energy starts getting spent, the tough and the long journey will ensure that in some time I will abandon this and go back to doing something else. Hence, the choice of problem itself is an important one because it is a resource. It is a resource of the mental and physical energy of the founders themselves. Hence, to begin with, choice of the problem is paramount for an entrepreneur. Once you are clear about the problem and you know that you have chosen a problem that you are passionate about solving, that if it gets solved, you will feel pride in its solution, then you need to create what is called the founding team. Here, I have taken a hypothetical example of a founding team with two members. Typically, a founding team is of anything between two to four members who come together to try and attack a problem they are equally passionate about. Now, as different people come together, the initial team has access to different skill sets. And those skill sets are skill sets of the members who have come together. So, in our hypothetical example, there is a person A and a person B, the two co-founders of the hypothetical organization that is getting formed. Now, there are two possibilities and they have been depicted on the slide by two Venn diagrams. The first one where the team of A and B has different skill sets and those skill sets have very little overlap. What it means is that the skill sets of A and skill sets of B are quite different from each other and have very little overlap between each of them. For example, one of the team members is very good at analytics, is very good with numbers and the other team member is possibly assuming that they are making an organization which will sell high quality cakes for birthday parties and certain functions of this kind. Let us assume that the skill set of B is about calculating the exact ingredient that should go into a high quality cake, how to bake it. So, the person B also is good at analytics of ingredients, but that is the only overlap with person A. The bulk of skill sets of co-founder B is focused on natural ingredients, on the process of baking and so on. So, they have very little overlap on their skill sets. Compare it with team two where the skill set of A and skill set of B have very high overlap. Now, which ones of these two founding teams is a magical team? Team one is the one which wins hands down. They have very high level of complementarity as it is called between A and B, which means that this initial team which has very little resource in the initial period, the only resource that a new venture has is its own founding team members and their skill sets, their energies and their skill sets. Now, if the skill sets have high overlap, it basically means that the cumulative area of the win diagram which is essentially the resource of the new team that has got formed is much lower for team two as compared to team one. And that is why the chances of team one to win this game is much higher than the chances of team two to win the game because team one has much higher resources at its command than team two. Now, where do you find co-founders with different skill sets, with complementary skill sets? It has been found by research that broadly there are two kinds of places where you can find your co-founders. One is serendipitous and the other is a goal directed arena. Now, what are these two kinds of arena? Serendipitous arenas are those where you find a co-founder by chance, serendipity is nothing but chance. So, there are certain arenas that we go to not to find a co-founder but just to socialize. For example, when we are in college in our dormitory or in our wings as it is called, we are not there to search for co-founder. But our next door roommate or the person who is in the same dormitory two beds away could be a potential co-founder. Similarly, if I am a guitarist and I go to play my guitar in a certain band or certain competitions and I do it regularly, there is a very high chance that I will find my co-founder in that social setting. If I am an adventure sports enthusiast then every weekend I would be going for something or the other which could be kayaking, which could be mountain climbing and so on and so forth. I might find my co-founder there. I did not go there to find the co-founder but I might find the co-founder there. So, this is what is called the serendipitous arena. Compare that with a goal directed arena which is also created increasingly in our society. For example, if I go to a pitching event, I might find a co-founder there over lunchtime. Now, this event itself has been arranged for a conversation between existing and potential founders and investors and other kinds of stakeholders interested in the entrepreneurial journeys. So, this arena is an arena where you would go with an intention to find your co-founder, your supporters. So, this is a goal directed arena. Another arena where you can find co-founders systematically is possibly an incubator, an accelerator, a hackathon conducted by various arms of the government of India or private entities as well. So, these are the two kinds of arenas where you will find your co-founders and depending on where you have found them, research tells that there could be certain differences. We should be aware of these differences. One, if you have found your co-founders in the serendipitous arena, chances are that the team size will be larger. As opposed to finding your co-founder in a goal directed arena, here because everybody has come to that particular arena to search for a co-founder with certain skill sets, the team size is smaller in such settings because they try to find the exact co-founder with exact complementary skill sets. Whereas in serendipitous arena, the idea is that we like to work with each other in certain other setting and now we are getting together to pursue a certain common dream. So, they are typically the team size becomes 3 or 4 whereas in a goal directed arena, typically the team size becomes 2 or at max 3. Again, the durability of the teams formed in such arenas also has been seen to be different. In a goal directed arena, because people are coming together explicitly to search for a co-founder, they have a certain idea in mind about what they want from this person. They have no other affection or relation with this person other than trying to find a co-founder. Hence, in relative terms, the durability of the teams formed in goal directed arena is a little lower than the durability of teams formed in serendipitous arenas. Now, because the durability of the team itself is something which is important to note, take note of, because we never know whether a certain team member will be able to withstand the pressure of a tough and long journey that we talked about initially. Hence, it is advised that every new team should finalize what is called a besting process for itself for the energies to continue to operate, for new energy to come into team in case somebody decides to move on and move away. For all of that, you have what is called a besting process. In a besting process, the shares of the team of the new organization been formed is not distributed immediately to the co-founders. For example, if there are two team members who have come together from a goal directed arena and have founded a new venture, you should not distribute 50% to the two team members and become equal owners of the organization, even if it is agreed that the two co-founders are going to be equal owners of the company. The ownership has to be given in phases over a period of time based on their ability to stick around and do the work that they had promised when they came together. So typically in the first 12 to 18 months, no share is given to the two co-founders. They themselves choose this besting rule for themselves so that they can test each other's commitment to being part of this team, this team which they are trying to create magic with and the besting process helps them reconfirm whether magic will indeed be created or not. So after period of one and a half years, typically over another two to three years, ownership is accorded to each co-founder as they stick around and make this new venture part of their life, part of their identity. So the besting process checks and re-checks the commitment of the co-founders and through this process it increases the chances of survival of the new venture which as we began with saying is a very tough journey to undertake. In between if one co-founder walks away for whatever reason, personal or professional reason, what the besting process ensures is that the venture still has enough shareholding to give to a new incoming co-founder. Imagine if the two co-founders had agreed that they would distribute 50% to each of them and the beginning the person moving away would have had 50% and that would have been practically the end of this new venture. Hence the besting process is a well accepted formula to ensure that teams continue creating magic either with the founders who came together in the beginning or with new co-founders who come in and the shareholding acts as the fuel to keep giving them the energy to move forward and solve the tough problem. We now move to the next phase of the entrepreneurial journey which is the initial team formation. Now how do you form an initial team that can continue to take forward the journey that the co-founders began with? After a certain period of time, the co-founders 2, 2, 3 or 4 of them do not have the bandwidth to do it on their own. They need more working hands. They need more partners who can collaborate with them, who can work with them hand in hand and take the company forward. For that they need to hire people. But why would somebody come and join a new venture which has possibly not sold a single unit, which has possibly not made any money, which has a very questionable future, a very uncertain future? Why would somebody come and start working in an organization like this? The answer to that is a long-term vision of the new venture. A vision which acts as a resource in attracting people to this fledgling organization. It is also called the North Star of the company. What is it that this company is trying to achieve? Do not talk about what is it that the new employees have to do? How hard they have to work? How many sacrifices they have to make? That is not going to attract a large number of people.  If your vision is articulated sharply, if your vision is articulated clearly, it will attract a certain kind of workforce. Not only will it attract a certain kind of workforce, once they come in, it will also act as a binding force because everybody has come in the organization looking at the North Star that you had painted, the vision that you had articulated. So, that is how you begin attracting high quality people into an organization which at the point in time when people come in has nothing much to offer to them. But when you have articulated a strong vision and you start getting a large number of applications for people to come in, you also need to be careful. You need to be careful that you hire the right kind of people. Now, who are these right kind of people? Well, the right kind of people are those people who have values and behaviors which match with what your understanding, your and your co-founders understanding of how this organization will behave. What will be the culture of the setup that is being created? How will we deal with customers? How will we deal with each other? How will we deal with ethical dilemmas and money and so on? So, it is suggested that once you have articulated your vision, sit down and list down 4 to 5 items which explain the values and behaviors that you are expecting from incoming employees. The co-founders should discuss this at great length because this is going to act as the filter, as the funnel through which employees will come into your initial team. Research has found that values and behaviors which are articulated with external stakeholders in mind, for example, the customers in mind, for example, your distributor, your retailer in mind, those kind of values and behaviors have been found to work better for new ventures rather than only those values and behaviors which talk about what will happen inside the organization. So, a good combination of externally focused values and behaviors and internally focused values and behaviors, but with greater emphasis on externally focused values and behaviors is suggested as you list down these 4 to 5 items through which every potential employee will have to pass through and act as a filter for hiring. Finally, what is suggested is that in this initial team that you are forming, you should cultivate diversity. Why should you cultivate diversity? When you already have a clear vision and you are solving a known problem, well it has been found that as initial teams start working and start experimenting in the market with their product or service that they are creating, they often undergo change in terms of what they think is useful for the market. Now, when this change comes to the forefront, it is only when you have a team with diverse opinions that you can find solution to your failing experiments. If you have created a highly homogenous team, the homogenous team might be very strong for a certain version of problem, but if that problem that you are solving itself changes, if your understanding of the customer segment that you are targeting was not as correct as you had initially thought to be, it is then when a diverse team with diverse opinions comes and starts solving the problem without breaking away. It is known to be more creative, it is known to be better at problem solving. So, in your hiring process you should have an explicit filter for ensuring that the team that gets formed comes from different parts of the country, from different backgrounds and so on and so forth. This will ensure that the team that you have formed is not only aligned in terms of values and behaviors, but has enough diversity to deal with various surprises that are going to come in the way of an entrepreneurial team as it progresses towards the product market fit. Thank you.