我可以创建一个空文件:
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是否会分配所有可用空间?“.由于我没有回答,我决定尝试.那么,让我们看看发生了什么.
让我们从我当前的系统开始,我在/ repository文件系统中只有3.3G的可用空间:
root@iMac-Chiara:~# df -h /repositoryfile 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=100+0 record dentro0+0 record fuori0 byte (0 B) copiati,000119606 s,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 /repositoryfile 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:~#
所以现在我在我的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: linuxDimensione blocco=4096 (log=2)Dimensione frammento=4096 (log=2)StrIDe=0 blocks,Stripe wIDth=0 blocks655360 inodes,2620928 blocks131046 blocks (5.00%) reserved for the super userPrimo blocco dati=0Maximum filesystem blocks=268435456080 gruppi di blocchi32768 blocchi per gruppo,32768 frammenti per gruppo8192 inode per gruppoBackup del superblocco salvati nei blocchi: 32768,98304,163840,229376,294912,819200,884736,1605632Allocating group tables: fatto Scrittura delle tavole degli inode: fatto Creating journal (32768 blocks): fattoScrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fattoroot@iMac-Chiara:~#
看起来它很有效,因为没有“空间不足”的轨迹.让我们检查:
root@iMac-Chiara:~# df -h /repositoryfile 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/secretfstune2fs 1.42.5 (29-Jul-2012)filesystem volume name: <none>Last mounted on: <not available>filesystem UUID: e63321c3-cee7-478d-a6af-cbdcaf1be1f7filesystem magic number: 0xEF53filesystem 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_isizefilesystem flags: signed_directory_hash Default mount options: user_xattr aclfilesystem state: cleanErrors behavior: Continuefilesystem OS type: linuxInode count: 655360Block count: 2620928Reserved block count: 131046Free blocks: 2541265Free inodes: 655349First block: 0Block size: 4096Fragment size: 4096Reserved GDT blocks: 639Blocks per group: 32768Fragments per group: 32768Inodes per group: 8192Inode blocks per group: 512Flex block group size: 16filesystem created: Sat Dec 12 19:58:05 2015Last mount time: n/aLast write time: Sat Dec 12 19:58:05 2015Mount count: 0Maximum mount count: -1Last checked: Sat Dec 12 19:58:05 2015Check interval: 0 (<none>)lifetime writes: 131 MBReserved blocks uID: 0 (user root)Reserved blocks gID: 0 (group root)First inode: 11Inode size: 256required extra isize: 28Desired extra isize: 28Journal inode: 8Default directory hash: half_md4Directory Hash Seed: c8b3bf1b-9f05-4267-85d3-2ecfdbaa6dc3Journal backup: inode blocks
是!看起来不错.
所以现在我们有一个EXT4文件系统写在一个打开的LUKS容器中,该容器定义在存储在3.3G文件系统中的10G稀疏文件之上.
通过“按需”分配空间,让我们看看一切是否正常.
让我们首先将500M的伪数据写入加密的FS
root@iMac-Chiara:~# mkdir /mnt/temproot@iMac-Chiara:~# mount /dev/mapper/secretfs /mnt/temproot@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/random_data.bin bs=1M count=512512+0 record dentro512+0 record fuori536870912 byte (537 MB) copiati,2,35214 s,228 MB/sroot@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 /repositoryfile system Dim. Usati dispon. Uso% Montato su/dev/sda3 275G 259G 2,5G 100% /repository
UAU!我们“失去”超过500M.这很好,BTW,因为物理空间真的按需分配!
让我们存储另一个2GB的文件:
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/another_random_data.bin bs=1G count=22+0 record dentro2+0 record fuori2147483648 byte (2,1 GB) copiati,25,6539 s,83,7 MB/sroot@iMac-Chiara:~#
发生了什么?
root@iMac-Chiara:~# ls -arlh /mnt/temptotale 2,6G-rw-r--r-- 1 root root 512M dic 12 20:09 random_data.bindrwx------ 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.bindrwxr-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 /repositoryfile system Dim. Usati dispon. Uso% Montato su/dev/sda3 275G 261G 484M 100% /repositoryroot@iMac-Chiara:~#
非常好.如果删除文件会怎么样?
root@iMac-Chiara:~# rm /mnt/temp/random_data.bin root@iMac-Chiara:~# syncroot@iMac-Chiara:~# ls -arlh /mnt/temptotale 2,1Gdrwx------ 2 root root 16K dic 12 19:58 lost+found-rw-r--r-- 1 root root 2,0K dic 12 20:14 .root@iMac-Chiara:~# df -h /repositoryfile system Dim. Usati dispon. Uso% Montato su/dev/sda3 275G 261G 484M 100% /repositoryroot@iMac-Chiara:~#
正如预期的那样,对于稀疏文件,行为与精简配置完全相同:一旦分配,在删除文件时无法声明存储空间.但总的来说,这是可以的.不是吗?
所以在这一点上,你的问题的答案应该是完整的.对?
加成:
让我们看看当下划线存储空间变满时会发生什么:
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/a_third_random_data.bin bs=1G count=22+0 record dentro2+0 record fuori2147483648 byte (2,26,7142 s,80,4 MB/sroot@iMac-Chiara:~#
什么?它看起来像是成功了!这怎么可能?让我们检查!
root@iMac-Chiara:~# ls -arlh /mnt/temptotale 4,0G dic 12 20:17 a_third_random_data.bin-rw-r--r-- 1 root root 2,0K dic 12 20:17 .root@iMac-Chiara:~#
嗯……看起来不错.我们确定吗?
root@iMac-Chiara:~# df /repositoryfile 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=UbuntudisTRIB_RELEASE=13.04disTRIB_CODEname=raringdisTRIB_DESCRIPTION="Ubuntu 13.04"root@iMac-Chiara:~# uname -r3.8.0-31-genericroot@iMac-Chiara:~# dpkg -l cryptsetup-bin[...]ii cryptsetup-bin 2:1.4.3-4ubuntu2 amd64 disk encryption support - command line toolsroot@iMac-Chiara:~#总结
以上是内存溢出为你收集整理的mount – 使用LUKS创建按需增长的加密卷全部内容,希望文章能够帮你解决mount – 使用LUKS创建按需增长的加密卷所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)