上上文书说道lvm的快照指定空间用满就会直接变成不可用，也没发现什么恢复的方法，觉得这设计不大好看啊。
今天看到了lvm的thin pool、thin volume，看看能不能解决这问题（snapshot也可以是thin volume），不过看完感觉这个貌似更奇葩。
这东西的资料甚少，gentoo.org上看到的说明是说thin volume对块设备来说就相当于稀疏文件（sparse files）对于文件系统一样。
简单说就是thin pool也是一个volume，不过这个volume是放volume的。
而thin volume就是这个放在volume中的volume。
但是thin volume的size要比thin pool的size大，这个是虚的不是实际从vg里分的size。
而thin pool是实际从vg里分得的空间。
也就是像稀疏文件似的，thin volume实际占用的空间没有他的size那么大（如果文件系统支持discard，则删除文件后空间可以释放，不会像qcow2镜像似的只扩不缩）。
但是奇葩的地方就在于，如果thin volume使用超过thin pool的size时，io就会被阻塞，也就是整个卡住了。这里不是那种Console里满屏提示神马I/O Error的那种（前提是指定的metadata空间够用，没有overflows，否则立马thin pool挂掉，满屏的I/O Error就真的出来了，而且这个是创建时指定，不能改），他这个是设计的就是卡在这了（这TM谁敢用啊！难怪搜不到神马资料。），等待扩充thin pool，也就是用lvextend增加足够的thin pool空间后，对thin volume的操作就活了，一切又变正常了。
引用原文的话就是
If the thin pool gets exhausted, any process that would cause thin pool to overrun will be stuck in “killable sleep” state until either the thin pool is extended or the process recieves SIGKILL.
但是实际的测试情况就是ls都卡在那里kill不能，so，关机都不顶用啊，扩展足够空间之后才响应的kill。
不过好歹volume还是可用状态，这点确实证明了它存在的意义。
结论就是，好奇怪的东西啊，完全不符合lvm高大上的气质，怪不得无人问津。
0 条评论。