主题的晦涩 人生的短暂
![kongjun18's Github chart kongjun18's Github chart](https://ghchart.rshah.org/kongjun18)
背景 LSM Tree 已经在 write-intensive database 中大量应用,但旧的实现存在以下问题: 严重的读写放大(read/write amplification) 没有充份利用 SSD 的内部并行性。 问题 1 尤为严重,LevelDB 的最坏情况下,写放大(从 L0 下沉至 L1)为 50,读放大(从 L0 读取所有 SST,再读穿到 L6)为 24×14 = 366。严重的读写放大不仅会导致 SSD 磨损,还会导致占用大量带宽。 [!NOTE] LevelDB 的读放大 读放大主
背景 目前 SSD 的 iops 已经能够达到百万 iops,但 Linux block layer 无法达到 iops。Linux block layer 成为了高速存储设备的性能瓶颈,为了绕开龟速的 block layer,许多开发者使用 bypass 技术在用户态进行 IO。 论文剖析了当前的 Linux block layer 设计,指出其性能瓶颈,并提出了面向多核系统和 SSD 的多队列设计。 瓶颈 Linux block layer 的性能瓶颈在于以下三点: 单一队列的锁竞争 每个设备一个队列,这个队列由一把全局锁保护。所有进程
背景和驱动 GFS(Google File System) 等存储系统为了高吞吐和高可用牺牲强一致性,本论文提出一种新复制协议链式复制(Chain Replication,简称 CR),在保持强一致性的前提下实现高吞吐和高可用。 本论文用 CR 协议讨论了对象存储的设计和实现。论文讨论的对象存储只有 query 和 update 两种操作,update 原子地更新对象。 接口 对象存储只提供两个接口: query(objId , opts ):查询某个对象的值。 update(objId , newVal , opts ):原
published on included in Security 背景 以往的内存安全 bug 检测方法,通常由编译器或内存分配器独立进行。编译器只理解程序语义,但无法在运行时工作;内存分配器只能在运行时工作,却无法感知程序语义。本文让编译器和内存分配器协同工作检测内存安全 bug。 目标 通过编译器和内存分配器协同设计,针对堆上的 buffer overflow 和 use-after-free 两种存安全 bug,提出更快且准确率高的检测方法。 论文主要面向 C/C++,并且要求源程序不存在整型到指
背景 hypervisor 控制整个 VM 的执行环境,因此可能高效地实现可容错的虚拟机系统。论文在 WMware vShpere 4.0 上实现了一个可用于生产环境的可容错虚拟机,称为 VMware FT。 设计 论文聚焦于如何实现一个可用与生产环境的容错虚拟机,更多聚焦于实现容错的策略(协议),底层使用的机制依赖于 VMware 的其他技术。虚拟机复制使用 VMware VMotion,这个技术原本用于迁移 VMware 虚拟机,VMware FT 稍作修改,用于复制虚拟机和重启
驱动 时钟可以用来标示系统中时间的发生次序,如果系统的所有进程的时钟都是同步的,那么系统中的所有进程就能达成关于事件次序的共识。然而,现实世界中时钟无法绝对同步,即使使用 NTP 等时钟同步技术,不同计算机间的时钟也会存在误差(NTP 误差为数十毫秒)。 此外,因为网络是不可靠的,不能以接收消息的顺序作为分布式系统中事件的发生顺序。 我们关注时钟,本质上是在关注系统中的事件