【发布时间】：2015-11-19 14:15:48
【问题描述】：
我在一个VG下有三个磁盘和三个PV（基于三个磁盘），然后我只是在VG上创建了一个LV并将LV挂载到文件夹/bigdisk。即将三个硬盘合并到一个文件夹/bigdisk。我的问题是当我将数据写入 /bigdisk 时，数据会同时条带化到三个磁盘吗？即三个磁盘是否会同时服务于输入操作以获得更好的 I/O 性能，就像 raid0 一样？
【问题讨论】：
标签： io disk hard-drive raid lvm
【发布时间】：2015-11-19 14:15:48
【问题描述】：
默认情况下，lvcreate 创建一个不会跨 PV 条带化的线性 LV；它只是将 PV 连接在一起。但是，您可以在创建 LV 时使用--stripes 和--stripesize 选项配置条带化。来自lvcreate的man页面：
-i, --stripes Stripes给出条纹的数量。这等于分散逻辑卷的物理卷的数量。
-I, --stripesize StripeSize给出条带粒度的千字节数。对于 LVM1 格式的元数据，StripeSize 必须为 2^n（n = 2 到 9）。对于 LVM2 格式的元数据，条带大小可能是 2 的较大幂，但不得超过物理范围大小。
vgcreate 创建的 VG 的默认物理范围大小为 4 MiB，因此在默认配置下，条带大小可以设置在 4 KiB 和 4 MiB 之间。
条带化由内核的device mapper 处理。您可以使用dmsetup 检查低级配置。
【讨论】：
当 LVM 与两个快速 SSD（每个超过 500MiB/s 的读取速度）和 4KiB 到 1MiB 的条带大小一起使用时，我贡献了一分，以及为什么我认为正在发生奇怪的速度松动。
案例 A：两个dd 命令行并行运行，带有两个控制台，每个控制台从不同的 SSD 读取，具有主板 SATA（非共享）通道；结果是速度是 SSD 速度的总和。
案例 B：在 LVM 中使用两个 SSD，带 4KiB 条带（类似于 RAID0）和dd 命令行运行以从条带逻辑卷中读取；结果是速度低于你从一个 SSD 获得的速度......真的很奇怪！但我认为它有一个解释。
案例 C：在 LVM 中使用两个 SSD，带 1MiB 条带（类似于 RAID0）和dd 命令行运行以从条带逻辑卷中读取；结果是速度比仅使用一个 SSD 快了近 1.3 倍……真的很奇怪！！！但我认为它有一个解释。
案例 D：使用两个旧的快速 (100MiB/s) 普通硬盘驱动器（磁性、旋转硬盘）进行测试，LVM 条带化速度接近 1.8 到 1.9 倍
那么，到底为什么在使用 SSD 时 LVM 剥离如此缓慢？我会试着解释一下我认为它发生在时间上的事件。
我将在该时间线中使用的图例：
- P = 系统要求 SSD 将数据发送到 ram（又名读取命令顺序）
- r = SSD 正在向 RAM 发送数据
- _ = 只是为了分开
- = 同时数据从两个 SSD 发送到内存
4KiB 条纹的时间线（效果被夸大以使问题可见）：
SSD A：ppppppRR____ppppppRR_____ppppppRR_ ...等等... SSD B: ______ppppppRR____ppppppRR_ ...等等... ：根本没有同时读取...等等...如您所见，大多数情况下，两个 SSD 都无所事事，根本不会发生同时读取；我夸大了发送到磁盘的请求时间与磁盘将数据发送到内存的时间之间的关系时间。
128KiB 条带的时间线（夸大效果以使问题可见）：
SSD A：ppppppRRRRRRRRRRppppppRRRRRRRRRRppppppRRRRRRRRRR ...等等... SSD B：______ppppppRRRRRRRRRRppppppRRRRRRRRRRppppppRRRRRRRRRR ...等等... ： ____________****____________****____________****______ ... 等等 ...如您所见，部分时间两个 SSD 会同时向内存发送数据，但同时读取是在短时间内；这是因为发送到磁盘的请求时间与磁盘发送数据到内存的时间之间的关系。
1MiB 条纹的时间线（夸大效果以使问题可见）：
SSD A：pRRRRRRRRRRRRRRRRRRRRpRRRRRRRRRRRRRRRRRRRR ...等等... SSD B：_pRRRRRRRRRRRRRRRRRRRRpRRRRRRRRRRRRRRRRRRRR ...等等... ： __*******************__*******************_ ... 等等 .. .如您所见，大多数情况下，两个 SSD 都同时向 RAM 发送数据，因此同时读取是在很长一段时间内；这是因为发送到磁盘的请求时间与磁盘发送数据到内存的时间之间的关系。
我认为可能是 LVM 按顺序向每个磁盘发送请求，一个接一个，循环磁盘，（请求 1 到 A，请求 2 到 B，请求 3 到 A，等等）。
如果请求时间占了将数据从 SSD 提供到 RAM 的总时间的很大一部分，即请求时间 >= 读取时间）将不会同时将数据发送到 ram，因此组合速度将低于仅从读取其中之一。
我认为 LVM 不会向每个磁盘发送一个条带列表，我认为 LVM 只是按顺序向每个磁盘发送一个条带。
因此，如果 LVM 向 SSD_A 请求一些条带（而不仅仅是一个条带），然后向 SSD_A 请求一些条带（不仅仅是一个条带），那么性能的一个巨大改进可能是，让我们看看 4KiB 条带的时间线（效果被夸大以使问题可见）：
SSD A：p1-4RRRRRRRRp1-4RRRRRRRRp1-4RRRRRRRRp1-4RRRRRRRR ...等等... SSD B: ____p1-4RRRRRRRRp1-4RRRRRRRRp1-4RRRRRRRRp1-4RRRRRRRR ...等等... ： ________****________****________****________****____ ... 等等 ...可以看出，通过发送一个由四个条带组成的请求，发送请求的时间是差不多的，但是每个SSD读取传输到RAM的时间会更长，所以读取可以同时发生，让我们看看是否代替请求四个条纹它会要求八个：
SSD A：p1-8RRRRRRRRRRRRRRRRp1-8RRRRRRRRRRRRRRRR ...等等... SSD B：____p1-8RRRRRRRRRRRRRRRRp1-8RRRRRRRRRRRRRRRR ......等等...... ： ________************________************____ ... 等等 ...更多时候，两个 SSD 会同时向 RAM 发送数据。
我根本不是专家，我没有研究 LVM 的代码，我刚刚用两个 SSD 测试了 dd 命令，只是改变了条带大小，发现在低条带大小 (4KiB) 的情况下，我的读取率较低使用两个 SSD 比单独使用其中一个更快。
希望有一天这有助于改进 LVM，并帮助人们不要因为 LVM 没有改进快速 SSD 而生气。
注意：快速 SSD 与连续读取 >500MiB/s 无关，它与它可以按顺序服务 4KiB 块的速度有关，请求一个接一个发送（我的给出 >35MiB/s 而大多数 SSD 会在队列深度为 1 的 4KiB 下提供略低于 1MiB/s 的速度）。
【讨论】：
我测试了性能：我使用scp从其他服务器复制一个大文件到lvm服务器。并使用iostat进行监控。我发现只有一个磁盘同时工作。所以答案是 LVM 不剥离数据并且写/读操作是串行的而不是并行的。
【讨论】：