是! 看起来有可能。让我们检查一下如何实现它。请注意,这不会创建真正的按需增长文件系统,因为当文件系统达到稀疏文件的最大大小时,如果仍然需要写入更多数据,它将报告“空间不足”错误。
最初,我正在研究Thin Provisioning,这是一种在虚拟化场景中节省存储空间的著名技术。不幸的是,在常见的Linux用例中,它似乎仅可用于LVM。由于这似乎超出了您的问题范围,因此我搜索了其他内容。
我研究的第二个概念是稀疏文件。这完全适合您的问题,...我最初的疑问是:“ 好。我可以创建一个稀疏文件。但是,当我将其初始化为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
好。因此,在以前具有3.3G可用空间的文件系统中,我们有一个10G的文件。我还有多少可用空间?
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
在存储只有3.3G可用空间的文件系统中的10G稀疏文件之上定义了一个打开的容器。
我还有多少可用空间?
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文件系统的创建DO需要大量的元数据的写入。因此,创建过程已经使用了一些空间是正常的。
它是“工作中”的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
是! 看起来还可以。
因此,现在我们在一个打开的LUKS容器中编写了一个EXT4文件系统,该容器定义在3.3G文件系统中存储的10G稀疏文件的顶部。
让我们通过“按需”分配空间来查看是否一切正常。
首先将500M的伪数据写入加密的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:~#
我们创建文件成功了吗?
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
au!我们“丢失”了超过500M。顺便说一句,这很好,因为物理空间实际上是按需分配的!
让我们存储另一个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:~#