qcow2 修改后端，导致文件系统腐败

关于使用qcow2的backing_file时可能会遇到的一个问题的分析与理解。

我们知道qcow2 的磁盘格式可以带来很大的便利性，因为部署的时候可以减少大量的时间、空间，可以增量备份、快照等非常诱人的特性。

因为下边可能会有点绕：
　　backing_file：后端，母镜像

　　qcow2：前端，子镜像

在使用的时候可能会遇到一种情况，就是使用backing_file时，如果修改了backing_file，“可能”会导致前端的qcow2 的崩溃，出现这种问题个人觉得是很正常的，并且是可以完全避免的。所以，在openstack在使用qcow2 的过程中会使用glance镜像管理来保证它的安全和完整性，我们在使用qcow2的时候也务必不回去修改它。

至于为什么会出现这种现象，下面简单分析一下，可能会有些纰漏、错误，但感觉整体思路上不会有太大的偏差。

什么是qcow2？

之前的博客也讲述过，qcow2：就是qemu的cow磁盘的第2版。既然是cow，必然是创建的前端磁盘内容是“空”的，即只有qcow2 磁盘格式的数据结构（当然包含backing_file的指针），而不包含任何磁盘内应该存放的实际内容。

我们启动虚拟机的时候，指定的是qcow2，但同时会加载backing_file（使用qmp，info block可以查看，或者/proc/$pid/fd/）。当读取文件的时候，根据qcow2 内部的指针指向backing_file，读取backing_file磁盘块上的内容。如果需要修改文件，则修改后的文件会保存到qcow2文件上。

那我们在使用backing_file特性时，再修改backing_file（后端）时可能就出现大概三种情况：

• backing_ing 删除或修改了qcow2中没修改过的内容

　　因为qcow2本来就没有什么数据，所有能查看到的数据都是通过backing_file的指针查看到的，所以当backing_file修改了，qcow2 还是直接去读backing_file，就相当于同步了，并不会有冲突或腐败。

• backing_ing 删除或修改了qcow2中修改过的内容

　　因为qcow2的cow机制，修改后的文件会保存到qcow2文件中，所以backing_file修改不会对qcow2文件造成任何影响，因为压根就没去读backing_file。（但有个前提，修改的幅度不应太大，如果文件的inode也变了，可能会造成冲突和错误（不过，这都不是重点！）

• backing_ing创建了qcow2中没有的内容

　　这种情况有点复杂，因为创建文件肯定会影响到文件系统的inode，如果这个inode没有在qcow2做修改的话，会直接读取backing_file,自然能够找到新添加的文件，如果qcow2的文件系统内的inode做了修改，我按照我自己的inode去找backing_file中的block发现对应不上，就会照成文件系统的损坏甚至崩溃；另一种情况是在qcow2中删除了一些文件或者将某个目录清空，然而在backing_file又在这个目录写了一些东西，qcow2中的inode中可能去查看到这个数据，但因为qcow2中的这块数据已经修改，不会去查看backing_file，就会导致有了inode，但找不到block。无论是有inode查看不到block还是inode删除，但block还在，不是我们所希望的。

 

所以，如果使用qcow2的backing_file，请务必保证其安全和完整性。