我正在尝试使用 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 文件将“扩展”图像，以使其足够大以包含该文件。
这有可能做到吗？
答案1
是的！看起来是可能的。让我们看看如何实现。请注意，这不会创建真正的按需增长文件系统，因为当文件系统达到稀疏文件的最大大小时，如果仍需要写入更多数据，它将报告“空间不足”错误。
最初，我在调查精简配置，这是在虚拟化场景中节省存储空间的著名技术。不幸的是，在常见的 Linux 用例中，它似乎仅适用于逻辑卷管理器。由于这似乎有点超出你的问题范围，所以我搜索了其他内容。
我研究的第二个概念是稀疏文件。这正好符合你的问题……我最初的疑问是：“好的。我可以创建一个稀疏文件。但是当我将其初始化为 LUKS 容器时会发生什么？这样的初始化会分配所有可用空间吗？如果不是，当我在这样的容器中初始化文件系统时会发生什么？会mkfs.ext4分配所有可用空间吗？“。由于我没有答案，我决定尝试一下。那么，让我们看看会发生什么。
让我们从我目前的系统开始，我只有3.3G文件系统内的可用空间/repository：
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
让我们创建一个10G此类文件系统中的稀疏文件：
root@iMac-Chiara:~# dd of=/repository/file_container.img bs=1G count=0 seek=10
0+0 record dentro
0+0 record fuori
0 byte (0 B) copiati, 0,000119606 s, 0,0 kB/s
让我们验证一下……这确实是一个稀疏文件：
root@iMac-Chiara:~# ls -lh /repository/file_container.img
-rw-r--r-- 1 root root 10G dic 12 19:48 /repository/file_container.img
好的。所以我们有一个10G文件，文件系统中之前有 3.3G 的可用空间。我还有多少可用空间？
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
仍然是 3.3G。不错。稀疏文件真的是……稀疏文件 ;-) 让我们继续，在这样一个 10G 文件中创建一个 LUKS 容器，然后……让我们看看是否空间不足：
root@iMac-Chiara:~# losetup /dev/loop0 /repository/file_container.img
root@iMac-Chiara:~# cryptsetup -y luksFormat /dev/loop0
WARNING!
========
Ciò sovrascriverà i dati in /dev/loop0 in modo irreversibile.
Are you sure? (Type uppercase yes): YES
Inserire la passphrase LUKS:
Verify passphrase:
root@iMac-Chiara:~# cryptsetup luksOpen /dev/loop0 secretfs
Inserire la passphrase per /dev/loop0:
root@iMac-Chiara:~#
因此现在我secrets在 10G 稀疏文件顶部定义了一个打开的容器，该文件存储在只有 3.3G 可用空间的文件系统中。
我还有多少可用空间？
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
太棒了！仍然只有 3.3GB。我们的加密容器几乎不占用任何空间！
让我们检查一下一切是否正常或者我们的设置是否有异常：
root@iMac-Chiara:~# cryptsetup status secretfs
/dev/mapper/secretfs is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/loop0
loop: /repository/file_container.img
offset: 4096 sectors
size: 20967424 sectors
mode: read/write
一切似乎都正常，所以让我们开始使用这样的容器来存储一些东西。让我们首先在其中创建一个 EXT4 文件系统：
root@iMac-Chiara:~# mkfs.ext4 /dev/mapper/secretfs
mke2fs 1.42.5 (29-Jul-2012)
Etichetta del filesystem=
OS type: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655360 inodes, 2620928 blocks
131046 blocks (5.00%) reserved for the super user
Primo blocco dati=0
Maximum filesystem blocks=2684354560
80 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
8192 inode per gruppo
Backup del superblocco salvati nei blocchi:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: fatto
Scrittura delle tavole degli inode: fatto
Creating journal (32768 blocks): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto
root@iMac-Chiara:~#
看起来它成功了，因为没有“空间不足”的痕迹。让我们检查一下：
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,2G 99% /repository
嗯……所以发生了一些事情。我们损失了大约 100M 的空间，但……这是预期的行为：创建了 EXT4 文件系统做需要写入大量元数据。因此创建过程占用一些空间是正常的。
它是一个“可以正常工作的” EXT4 文件系统吗？
root@iMac-Chiara:~# tune2fs -l /dev/mapper/secretfs
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: e63321c3-cee7-478d-a6af-cbdcaf1be1f7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 655360
Block count: 2620928
Reserved block count: 131046
Free blocks: 2541265
Free inodes: 655349
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 639
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Dec 12 19:58:05 2015
Last mount time: n/a
Last write time: Sat Dec 12 19:58:05 2015
Mount count: 0
Maximum mount count: -1
Last checked: Sat Dec 12 19:58:05 2015
Check interval: 0 (<none>)
Lifetime writes: 131 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: c8b3bf1b-9f05-4267-85d3-2ecfdbaa6dc3
Journal backup: inode blocks
是的！看起来还不错。
所以现在我们有一个 EXT4 文件系统，它写在一个打开的 LUKS 容器内，该容器定义在 3.3G 文件系统内存储的 10G 稀疏文件之上。
让我们通过“按需”分配空间来看看一切是否正常运行。
首先将 500M 的虚拟数据写入加密文件系统
root@iMac-Chiara:~# mkdir /mnt/temp
root@iMac-Chiara:~# mount /dev/mapper/secretfs /mnt/temp
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/random_data.bin bs=1M count=512
512+0 record dentro
512+0 record fuori
536870912 byte (537 MB) copiati, 2,35214 s, 228 MB/s
root@iMac-Chiara:~#
我们是否已成功创建该文件？
root@iMac-Chiara:~# ls -lh /mnt/temp/random_data.bin
-rw-r--r-- 1 root root 512M dic 12 20:09 /mnt/temp/random_data.bin
看起来是这样的。
我们的真实文件系统发生了什么？
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 259G 2,5G 100% /repository
哇！我们“损失”了 500 多兆。顺便说一句，这很好，因为物理空间确实是按需分配的！
我们来存储另一个 2GB 的文件：
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/another_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 25,6539 s, 83,7 MB/s
root@iMac-Chiara:~#
发生了什么？
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,6G
-rw-r--r-- 1 root root 512M dic 12 20:09 random_data.bin
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:12 .
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 261G 484M 100% /repository
root@iMac-Chiara:~#
真不错。如果我们删除一个文件会发生什么？
root@iMac-Chiara:~# rm /mnt/temp/random_data.bin
root@iMac-Chiara:~# sync
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,1G
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:14 .
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 261G 484M 100% /repository
root@iMac-Chiara:~#
正如预期的那样，稀疏文件的行为与精简配置完全相同：一旦分配，文件被删除时就无法收回存储空间。但总的来说，这是可以接受的。你不这么认为吗？
至此，你的问题的答案应该完整了。对吗？
添加：
让我们看看当下划线存储空间已满时会发生什么：
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/a_third_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 26,7142 s, 80,4 MB/s
root@iMac-Chiara:~#
什么？看起来成功了！这是怎么可能的？让我们检查一下！
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 4,1G
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:17 a_third_random_data.bin
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:17 .
root@iMac-Chiara:~#
嗯...看起来还不错。我们确定吗？
root@iMac-Chiara:~# df /repository
File system 1K-blocchi Usati Disponib. Uso% Montato su
/dev/sda3 288110208 275070448 0 100% /repository
我们已经用完了空间！没有任何错误！
即使调查到底发生了什么事情会很好...我将把这个问题留给您的好奇心和/或其他 ServerFault 成员的故障排除技能 ;-)
玩得开心！
顺便说一句：我已经测试了以上所有内容，如下所示：
root@iMac-Chiara:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"
root@iMac-Chiara:~# uname -r
3.8.0-31-generic
root@iMac-Chiara:~# dpkg -l cryptsetup-bin
[...]
ii cryptsetup-bin 2:1.4.3-4ubuntu2 amd64 disk encryption support - command line tools
root@iMac-Chiara:~#