关于 longhorn 快照的自问自答

以下内容未经过源码查验. 如有错误, 欢迎指出.

一块1G的磁盘, 要先划定用来存储 快照的区域, 这样, 实际最大寻址的 就不是1G, 比如说, 只有800MB, 是这样吗?
答: 不是这样的, 而是就没有直接寻址的. 读取都需要查询映射表. 换句话说, 整块磁盘都用来存放快照.

快照是存放在文件系统上, 还是 没有块设备上, 划一块区域 存快照?
答: 不是存放在文件系统上.

live data是写到 实际磁盘位置上(不需要映射), 对吗?
答: 好像不是.

backup 还是 跟 快照存放在同一块磁盘上吗?
答: 不是的. 快照向上层 展示了 线性的磁盘, 而其实现是 映射表. backup是对 快照的整合, 若放在同一个磁盘上, 则会干扰 映射关系.

快照自身是需要存储 地址的, 否则无法通过 快照来构建 backup. backup展示的是 线性的空间, 还是需要映射? 或者说, backup是否需要存储 块的地址(起始地址)?
答: 文档提到 backup每块是2M, 由此可猜想, backup的组织形式 地址是递增的, 但地址可以不连贯, 也就是允许 2M的块 之间有 断开. 所以, 需要存储块的起始地址. disaster recovery (DR) volume 才是不需要起始地址的, 因为是volume.

disaster recovery (DR) volume 不需要起始地址?
答: 如果是这样的话, 主备两端的逻辑 岂不是不能复用了? 可以复用. 初始映射表, 都映射到 DR卷上, 后续写再修改映射表. 也就是 映射表 的目的地 可以是 两个不同的卷.

建立一个backup后, 第2个backup是否需要包含第1个backup?
答: 要的. 不过由于 backup是由obj组成的, 每块2MB, 所以, 可以存在共用的obj.

各个backup 之间 是否存在 交叉/重叠的 磁盘地址区间/范围?
答: 参考上一个问题.

问题: live 数据 和 快照的不同?
答: live 是可读写，快照是只读

写时拷贝 (Copy-On-Write)，COW
写时重定向 (Redirect-On-Write)，ROW
问题: longhorn属于哪个?
答: longhorn是ROW的.
COW的快照卷存放的是原始数据， 而 ROW的快照卷存放的是新数据.
ROW的写性能基本没有损耗, 但是其数据会变得非常离散, 所以其连续读写性能不如COW.
在分布式场景下，读取通常不是性能瓶颈, 数据越分散, 性能越高, ROW 的一个场景是用在分布式中.

关于cow方式的快照
答: 更改数据时，会拷贝旧数据到快照卷，源数据会被覆盖, ，快照指针表的地址会更新, 后续的写映射到 数据卷. 快照卷是只读的.
优点：原始卷物理块连续.
缺点：降低源数据卷的写性能

本文地址: https://awakening-fong.github.io/posts/distributed_system/longhorn_snapshot_qa

转载请注明出处: https://awakening-fong.github.io