- 博客(11)
- 收藏
- 关注
RSS订阅原创 Lab 2C
中的添加 Xterm Xindex，主要是Xinex 来告诉Leader的nextIndex 该退回到哪里，然后感觉这里的Xterm作用不大（课程上面也有人提到这个的作用是什么，老师回答比较模糊，意思就是取决于你的实现），这里我吧Xterm 为-1的时候表示follower没有任何的log，也就是需要把nextIndex设置为1。的实验的纯代码可能要写就十分钟就写完了，但是测试还是很难全部通过，这边我们不贴全部代码了，还是很简单的。相比于2A与2B的实现多了几处修改的地方，代码放在这里了，可以去看看。
2024-04-16 11:21:11
275
原创 raft_guide理解与翻译
因为如果有的心跳RPC由于网络等问题，时过时的心跳RPC，但是有没有错误，这时如果我们截断后面的entry，会导致丧失了很多entry，而leader不知道。当所有的服务器、网络等外部因素都是没有错误的情况下，共识算法都是很好理解的，但是实际的应用中，算法必须考虑到每一个可能发生的错误，而这里面的细节就是相当复杂的。，但是这是可能是错误的，因为在接收和发送RPC之间，服务器可能会有其他的更新操作，所以我们不能直接的使用服务器当前的字段来更新，而应该用我们发送RPC时传入的参数来进行更新相关的操作。
2024-04-16 10:04:59
326
原创 GFS笔记
虽然改写不会涉及到重新写的问题，但是改写会存在这样的问题：一个改写操作很可能涉及到一个文件多个chunk的改写，如果部分chunk成功，部分chunk失败，我们读到的文件就是错误的！原因是 一个 改写操作可能涉及到多个chunk，而租约决定的控制流只能保证相同chunk副本之间执行的顺序一致，而不同chunk 很可能会选择不同的执行顺序，又一个执行改写会操作多个chunk 所以会导致最终的chunk出现问题。master中的元数据时非常重要的，而GFS选择实现的是单中心节点，而非分布式的中心节点。
2024-04-16 09:54:32
639
原创 Lab1 MapReduce
读完谷歌的MapReduce的论文，基本上就会对这个分布式模型设计有了初步的认识，这里就不过多介绍。来具体看看lab1的 任务要求task: 在现有的顺序MapReduce程序中，设计一个分布式的实现。包括coordinator以及worker。worker通过RPC与coordinator通信，每一个woker都会询问一个任务，从文件中读取输入，执行任务，并且将输出写入到files中。
2024-04-16 09:52:30
932
原创 Traps and system calls
原因是内核在给每一个用户进程分配内存的时候，都会将同一段代码的，也就是这列的trampoline代码映射给用户的虚拟空间，同时这段代码的用户的虚拟空间地址，与内核中的虚拟空间地址是一样的，所以尽管切换了代码，但是还是能够在内核页表的映射下也能正确执行。COW 的总体思路就是fork()的时候不拷贝物理内存，只是让新的进程的页表 有着与父进程相同的映射，这样就不存在浪费时间复制了，当然子进程的页表项中会将这也映射设置成只读不可写，当子进程需要写时，就会把内存的拷贝，然后在新的拷贝上面去写。
2023-08-23 21:34:50
86
1
原创 page tables
有了页表的存在，每一个进程实际的物理地址就不可能冲突，此外页表还可以让多个虚拟地址映射到相同的物理地址上来节约内存（例如每一个进程中断都要进去的trampoline代码段），以及页表还能以一种简单的方法来保护内核或者用户栈。当然这都是猜测，后面肯定要具体学linux的页表的。每一个进程都有自己的用户页表，但是所有进程都是共享内核的，所以每一个进程都需要一个用户页表，但是所有进程的内核只需要一个内核页表。总的来说这些函数中，开头带有kvm的是操作内核页表的，开头带有uvm的是操作用户页表的。
2023-08-23 21:33:06
82
1
原创 Operating system organization
这一节课本介绍了一些硬件资源的抽象以及这样抽象的原因。在第一章的时候已经简单介绍过了。这里就不赘述。
2023-08-04 16:06:18
45
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人