我正试图在Linux中创build一个encryption的，不断增长的文件系统。 我熟悉LUKS和cryptsetup。
我可以创build一个空文件：
fallocate -l 512M /root/image 我可以在它上面创build一个LUKS容器：
cryptsetup -y luksFormat /root/image
然后“打开”它：
cryptsetup luksOpen /root/image luksvolume
在这一点上，我可以制作一个文件系统：
mkfs.ext4 -j /dev/mapper/luksvolume
这一切都很好，很棒。 但是，这并不涉及问题的“按需增长”部分。
这个想法是，在encryption的文件系统上复制一个2Gb文件将“扩展”图像，使其足以容纳该文件。
这甚至有可能吗？
是! 看起来可能。 让我们来看看如何实现。
最初，我正在研究Thin Provisioning ，这是一种在虚拟化场景中节省存储空间的知名技术。 不幸的是，在常见的Linux使用情况下，它似乎只适用于LVM 。 由于这似乎超出了你的问题的范围，我寻找了其他的东西。
我调查的第二个概念是稀疏文件 。 这是完全适合你的问题和…我最初的疑问是：“ 好吧，我可以创build一个稀疏文件，但是当我初始化为一个LUKS容器时会发生什么？这样的初始化会分配所有可用的空间吗？当我在这样一个容器中初始化文件系统时会发生什么？ mkfs.ext4分配所有可用的空间吗？ “ 由于我没有答案，我决定尝试。 所以，让我们看看发生了什么。
从我目前的系统开始，我在/repository文件系统中只有3.3G的可用空间：
root@iMac-Chiara:~# df -h /repository File system Dim. Usati Dispon. Uso% Montato su /dev/sda3 275G 258G 3,3G 99% /repository
让我们在这样的文件系统中创build一个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
我们来validation一下…这真的是一个稀疏的文件：
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可用空间的文件系统中。 我还有多less可用空间？
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文件中创build一个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的可用空间的文件系统。
我还有多less可用空间？
root@iMac-Chiara:~# df -h /repository File system Dim. Usati Dispon. Uso% Montato su /dev/sda3 275G 258G 3,3G 99% /repository
精彩！ 仍然3.3GB。 我们的encryption容器大多不需要空间！
让我们来看看是否一切正常或者我们的设置有什么奇怪的地方：
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
一切都好了，让我们开始使用这样一个容器来存储的东西。 我们先从里面创build一个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的空间，但是……这是一个预期的行为：创buildEXT4文件系统DO需要写入大量的元数据。 所以创build过程中使用了一些空间是正常的。
这是一个“工作”的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文件系统，它是在一个在3.3G文件系统中存储的10G稀疏文件顶部定义的打开的LUKS容器中编写的。
让我们看看是否一切正常，通过分配空间“按需”。
让我们开始写500M的虚拟数据到encryption的FS
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:~#
我们是否已经成功创build文件？
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
UAU！ 我们“迷失”了5亿多。 顺便说一句，顺便说一下，物理空间是按需分配的！
让我们另存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:~#
正如所料，使用稀疏文件的行为就像精简configuration一样：一旦分配，存储空间不能在文件被删除时被回收。 但总的来说，这是可以的。 你不是吗？
所以在这一点上，你的问题的答案应该是完整的。 对？
加成：
让我们来看看当下划线存储变满时会发生什么：
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成员的故障排除技巧;-)
玩的开心！
顺便说一句：我已经testing了以上所有，在这里：
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:~#