Sim! Parece que é possível. Vamos verificar como isso pode ser alcançado.
Inicialmente, eu estava investigando o Thin Provisioning , uma tecnologia bem conhecida para economizar espaço de armazenamento em cenários de virtualização. Infelizmente, em casos comuns de uso do Linux, parece estar disponível apenas com LVM . Como isso parece um pouco fora do escopo da sua pergunta, eu procurei por outra coisa.
O segundo conceito que eu investiguei é Sparse File . Isso é exatamente adequado à sua pergunta e ... minha dúvida inicial foi: " OK. Eu posso criar um arquivo esparso. Mas o que acontece quando eu inicializo como um contêiner LUKS? Essa inicialização aloca todo o espaço disponível? Se não, o que acontecerá quando eu inicializar o sistema de arquivos em tal contêiner? Um mkfs.ext4 alocará todo o espaço disponível? ". Como não tive resposta, decidi tentar. Então, vamos ver o que aconteceu.
Vamos começar pelo meu sistema atual, onde tenho apenas 3.3G de espaço livre dentro do sistema de arquivos /repository :
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Vamos criar um arquivo esparso 10G dentro desse sistema de arquivos, com:
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
e vamos verificar se ... é realmente um arquivo esparso:
root@iMac-Chiara:~# ls -lh /repository/file_container.img
-rw-r--r-- 1 root root 10G dic 12 19:48 /repository/file_container.img
OK. Portanto, temos um arquivo 10G , em um sistema de arquivos que anteriormente tinha 3.3G de espaço livre. Quanto espaço livre ainda tenho?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Ainda 3.3G. Agradável. O arquivo esparso é realmente ... sparse-file ;-) Vamos dar um passo à frente, criando um contêiner LUKS dentro de um arquivo 10G e ... vamos ver se ficamos sem espaço:
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:~#
Portanto, agora tenho um contêiner secrets aberto definido em cima do meu arquivo 10G esparso armazenado em um sistema de arquivos com apenas 3.3G de espaço livre.
Quanto espaço livre ainda tenho?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Maravilhoso! Ainda 3,3 GB. Nosso contêiner criptografado praticamente não requer espaço!
Vamos verificar se está tudo bem ou se há algo estranho em nossa configuração:
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
Tudo parece OK, então vamos começar a usar esse contêiner para armazenar algo. Vamos começar criando um sistema de arquivos EXT4 dentro dele:
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:~#
Parece que funcionou, pois não havia faixa de "espaço fora do ar". Vamos verificar:
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,2G 99% /repository
Uhm .... então algo aconteceu. Perdemos algo como 100M de espaço, mas ... é um comportamento esperado: a criação do sistema de arquivos EXT4 DO requer a gravação de muitos metadados. Então é normal que algum espaço tenha sido usado pelo processo de criação.
É um sistema de arquivos EXT4 "funcional"?
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
Sim! Parece ok.
Portanto, agora temos um sistema de arquivos EXT4 escrito dentro de um contêiner LUKS aberto, definido em cima de um arquivo 10G esparso armazenado dentro de um sistema de arquivos 3.3G.
Vamos ver se tudo funciona corretamente, alocando espaço "sob demanda".
Vamos começar escrevendo 500 milhões de dados fictícios para o FS criptografado
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:~#
Temos sido bem sucedidos na criação do arquivo?
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
Parece que sim.
O que aconteceu com nosso sistema de arquivos real?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 259G 2,5G 100% /repository
Uau! Nós "perdemos" pouco mais de 500 milhões. Isso é bom, BTW, como o espaço físico é realmente alocado sob demanda!
Vamos armazenar outro arquivo de 2 GB:
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:~#
O que aconteceu?
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:~#
Muito bom. O que acontece se excluirmos um arquivo?
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:~#
Como esperado, com o arquivo esparso, o comportamento é exatamente como o thin-provisioning: uma vez alocado, o espaço de armazenamento não pode ser recuperado quando o arquivo é excluído. Mas isso, em geral, está bem. Você não?
Então, neste ponto, a resposta à sua pergunta deve estar completa. Certo?
Adição:
Vamos ver o que acontece quando o armazenamento de sublinhado fica cheio:
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:~#
O que? parece que foi bem sucedido! Como isso foi possível? Vamos checar!
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:~#
Uhm ... parece ok. Temos certeza?
root@iMac-Chiara:~# df /repository
File system 1K-blocchi Usati Disponib. Uso% Montato su
/dev/sda3 288110208 275070448 0 100% /repository
ficamos sem espaço! Sem qualquer erro!
Mesmo que seja bom investigar o que realmente aconteceu ... vou deixar isso para sua curiosidade e / ou habilidades de solução de problemas de outros membros do ServerFault; -)
Divirta-se!
BTW: testei todos os itens acima, aqui:
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:~#