现在我们从原处删除a.test.file，并且检查它是否仍然在快照里： 

# rm /mnt/a.test.file 
# ls /snap 
total 13 
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file 
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found 

太令人惊讶了！ 

7.1 它是如何工作的？ 
记得我们不得不设置“--size”参数吗？真正发生的事情是，“snap”卷需要有那些当LVM调用时，在原处要被改变的所有块的一个拷贝。 

当我们删除a.test.file时，它的i节点被删除。这引起64KB要被标注成“脏的”--同时原始数据的一个拷贝被写到“snap”卷。这个例子中，我们分配了16MB给快照，因此如果多于16MB的块要被修改，快照就会无效了。 

要决定一个快照分区的正确大小，你将不得不推测基于主LV的使用模式、快照要激活的总时间。例如，在午夜，当无人使用系统的情况下，一个几小时的备份可能要求很小的空间。 

请注意，快照不是永久的。如果你卸下LVM或重启，它们就丢失了，需要重新创建。 

-------------------------------------------------------------------------------- 

8. 冗余 & 性能 
为了性能的考虑，可以将数据分散在几个条块化的磁盘上。这意味着块1在PV A上，块2在PV B上，块3又在PV A上。你也可以条块化跨多余2块磁盘。 

这样的安排意味着你有更多有效的磁盘带宽。也就是说包含了更多的“轴”。以后会详述。 

除此之外，为了提高性能，也可以将你的数据在多个磁盘上有多份拷贝。这叫做镜像。目前，LVM本身还不支持它，但是有多种方法能实现镜像。 

8.1 为何要条块化？ 
磁盘的性能至少受三种因素的影响。最明显的是一块磁盘上的数据能连续被读或写的速度。这是当读或写仅连接了一个单一的磁盘的SCSI/IDE总线上的一个大文件时的限制因素。 

接着是到磁盘的有效带宽。如果你在一个SCSI总线上有7块盘，这也许会小于你的磁盘本身写的速度。如果你愿意花足够的钱，你可以避免这个瓶颈成为一个问题。 

然后是响应时间。当成谚语说，响应时间总是坏消息。甚至更坏的是，你不可能通过花更多的钱来降低响应时间！现在出产的大多数磁盘有一个大约7ms的响应时间。还有SCSI响应时间，通常是大约25ms。 

FIXME: need recent numbers! 

这意味着什么？在一个典型情形，总的响应时间大约是30ms。因此你每秒钟只能执行大约33个磁盘操作。如果你想每秒钟能做数千个查询，并且你没有大量的缓存，那么你就非常不走运了。 

如果你有多个磁盘，或者“轴”，在并行工作，那么你可以有多个命令很好地围绕你的响应问题同时执行。有些应用程序，比如一个大的新闻服务器，如果没有条块化或其它I/O敏捷性它甚至不再工作。 

这就是条块化做的事。如果你的总线能胜任，甚至连续的读和写可能会更快。 

8.2 为何不条块化 
条块化没有进一步的措施来解除你的错误机会，按一个“每次一比特”的基本原则。如果你的磁盘任一块死了，你全部的逻辑卷都会丢失。如果你正好连接数据，仅仅文件系统部分丢失。 

最终的选项是镜像的条块化。 

FIXME: make a mirrored stripe with LVM and md 

8.3 LVM本身的条块化 
当用lvcreate创建LV时，指定条块化配置项。有两个相关参数。-i参数告诉LVM应该在多少个PV上分散数据。条块化不是真的按一次一比特的基础来做的，而是按块。-I参数指定单位为KB的块大小。注意它必须是2的一个幂，而且最大的块大小为128KB。 

例如： 

# lvcreate -n stripedlv -i 2 -I 64 mygroup -L 20M