我正在尝试在 Linux 中创建一个加密的、按需增长的文件系统。我熟悉 LUKS 和 cryptsetup。
我可以创建一个空文件：
fallocate -l 512M /root/image
我可以在上面创建一个 LUKS 容器：
cryptsetup -y luksFormat /root/image
然后“打开”它：
cryptsetup luksOpen /root/image luksvolume
此时，我可以在其上创建一个文件系统：
mkfs.ext4 -j /dev/mapper/luksvolume
这一切都很好，花花公子。但是，它没有解决问题的“按需增长”部分。
这个想法是在加密文件系统上复制一个 2Gb 文件将“扩展”图像，使其足够大以包含该文件。
甚至有可能做到吗？
是的！看起来有可能。让我们看看它是如何实现的。请注意，这不会创建真正的按需增长文件系统，因为当文件系统达到稀疏文件的最大大小时，如果仍需要写入更多数据，它将报告“空间不足”错误。
最初，我正在研究Thin Provisioning，这是一种在虚拟化场景中节省存储空间的著名技术。不幸的是，在常见的 Linux 用例中，它似乎仅适用于LVM。由于这似乎超出了您的问题范围，因此我搜索了其他内容。
我研究的第二个概念是Sparse File。这完全适合您的问题，并且......我最初的疑问是：“好的。我可以创建一个稀疏文件。但是当我将它初始化为 LUKS 容器时会发生什么？这样的初始化会分配所有可用空间吗？如果没有，当我在这样的容器中初始化文件系统时会发生什么？会
mkfs.ext4分配所有可用空间吗？ ”。由于没有答案，我决定试一试。那么，让我们看看发生了什么。让我们从我当前的系统开始，我在文件系统中只有3.3G的可用空间
/repository：让我们在这样的文件系统中创建一个10G稀疏文件，其中：
让我们验证一下……它确实是一个稀疏文件：
好的。所以我们有一个10G的文件，在一个以前有 3.3G 可用空间的文件系统中。我还有多少可用空间？
还是3.3G。好的。稀疏文件真的是……稀疏文件；-) 让我们先一步，在这样一个 10G 的文件中创建一个 LUKS 容器，然后……让我们看看是否空间不足：
所以现在我
secrets在我的 10G 稀疏文件之上定义了一个打开的容器，存储在一个只有 3.3G 可用空间的文件系统中。我还有多少可用空间？
精彩的！还是3.3GB。我们的加密容器几乎不需要空间！
让我们检查一下是否一切正常，或者我们的设置是否有什么奇怪的地方：
一切似乎都很好，所以让我们开始使用这样的容器来存储一些东西。让我们首先在其中创建一个 EXT4 文件系统：
看起来它起作用了，因为没有“空间不足”的痕迹。让我们检查：
嗯……所以出事了。我们丢失了大约 100M 的空间，但是....这是预期的行为：EXT4 文件系统的创建确实需要写入大量元数据。所以创建过程使用了一些空间是正常的。
它是一个“工作”的 EXT4 文件系统吗？
是的！看起来不错。
所以现在我们在一个打开的 LUKS 容器中编写了一个 EXT4 文件系统，该容器定义在一个 3.3G 文件系统中存储的 10G 稀疏文件之上。
让我们通过“按需”分配空间来看看一切是否正常。
让我们首先将 500M 的虚拟数据写入加密的 FS
我们是否已成功创建文件？
看起来是这样。
我们的真实文件系统发生了什么？
哇！我们“损失”了 500M 以上。这很好，顺便说一句，因为物理空间真的是按需分配的！
让我们再存储一个 2GB 的文件：
发生了什么？
非常好。如果我们删除一个文件会发生什么？
正如预期的那样，稀疏文件的行为与精简配置完全相同：一旦分配，删除文件时就无法收回存储空间。但是，总的来说，这是可以的。不是吗？
所以在这一点上，你的问题的答案应该是完整的。正确的？
添加：
让我们看看当下划线存储已满时会发生什么：
什么？看起来它成功了！这怎么可能？让我们检查！
嗯……看起来还可以。我们确定吗？
我们的空间已经用完了！没有任何错误！
即使调查真正发生的事情会很好......我将把它留给您的好奇心和/或其他ServerFault成员的故障排除技能;-)
玩得开心！
顺便说一句：我已经测试了以上所有内容，在这里：